Null-restricted types: Why so complicated?

[Pedro Lamarão]

Em sex., 19 de jan. de 2024 às 14:53, - <liangchenblue at gmail.com> escreveu:


> On Fri, Jan 19, 2024 at 10:07 AM John Bossons <jbossons at gmail.com> wrote:
>
>> Thanks for your comments. I was not sufficiently explicit.
>>
>> Let me focus on implicit. I guess my dislike is of introducing a 'fake'
>> constructor into the definition of a class. I say 'fake' because, as I
>> understand it, the only purpose of the implicit constructor is to indicate
>> to the JVM/compiler that a never-null instance can be created. But in Java
>> idiom that means that a developer can invoke the public implicit
>> constructor, which will cause confusion.
>>
>

> It is a real constructor like that default no-arg one generated by javac,
> and developers always CAN invoke that constructor. It is, however, a
> watered-down version, because our existing default one can perform side
> effects like `private List<Integer> values = new ArrayList<>();` injected
> to the end of constructor, while the implicit one must give it up so that
> JVM can construct zero instances cheaply yet correctly. As a result, this
> constructor cannot declare any side-effect code or declare a custom
> superconstrctor call, so it will look like a "fake" one, yet it is no
> different from a true constructor.
>

C++ has the following notation for a compiler-generated "default"
constructor.
It has been in place for some years and has been well received.
The meaning of the existing C++ "default" and the meaning of the proposed
Java "implicit" is very similar.
I am not aware of the meaning of "default" being particularly difficult to
teach.

class foo
{
   foo () = default;
};

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240119/e84e3d9c/attachment.htm>