[External] : Re: User model stacking

[Victor Nazarov]

Hello Brian,

I've got some comments to the current discussion. I hope that they may be
helpful.

On Thu, Apr 28, 2022 at 1:13 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> Some of the characteristics of this scheme:
>
> - The default is atomicity / integrity FOR ALL BUCKETS (safe by default)
> - The default is nullability FOR ALL BUCKETS
> - All unadorned type names are reference types / nullable
> - All Val-adorned type names (X.val) are non-nullable (or .zero, or
> .whatever)
> - Atomicity is determined by declaration site, can’t be changed at use site
>
>

Why do we need a use-site opt-in into a zero-happiness?
I thought that the main concern with zero-happiness was a risk of tearing,
but in the proposed model tearing is always controlled by the
declaration-site annotation, so why do we need use-site opt-in? For me
"zero-happiness" of the type means that the type is happy to be zero, which
sounds like zero is a better default from the type point of view then null.
If a user knows better about a particular use-site, then it's ok to
override this with ".ref". We already have primitives that have
zero-default values (int, long, ...), they are not written as "int.val" or
"int!", are we going to recommend everybody to write "Integer!" instead of
"int"?



> The main syntactic hole is finding the right spelling for "zeroable" /
> .val.  There is some chance we can get away with spelling it `T!`, though
> this has risks.
>
> Spelling zero-happy as any form of “flat” is probably a bad idea, because
> B2 can still be flat.
>


Syntax wise I think I would support something that Remi Forex promoted for
quite some time: highlighting that zero-happy classes have default
constructor, something like:

relaxed value class Complex {
    // Default value of type Complex is one generated by default
constructor of class Complex
    default Complex();
}