Records -- current status

[Remi Forax]

----- Mail original -----
> De: "Guy Steele" <guy.steele at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 29 Mars 2018 21:25:56
> Objet: Re: Records -- current status

> I've always assumed that, eventually, if we wanted too, we could always spell it
> as
> 
>      !final
> 
> That also makes possible such explicit declarations as !volatile and !transient
> . . . And possibly even !null.
> 
>      !final !null String x = "quux";  // mutable, but you can't set it to null
> 
> —Guy

!final is a property of the variable while !null is more a property of the type.

I see no problem to have a keyword 'mut' like in Rust instead of !final.
But before i think we need to have a way to reverse the defaults or at least spell them by example at module declaration.

  default field final, parameter final, variable mut;
  default ref nonnull;    

Rémi

> 
> Sent from my iPhone
> 
>> On Mar 29, 2018, at 2:39 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> 
>>> What else could we do? Don't take these random ideas too seriously, but: maybe
>>> the declaration is a "mutable record"? Or just a "class", with some other
>>> signal that many record-like features are relevant? Or maybe the mutable fields
>>> appear in a different context?
>>> 
>>> I feel like we could probably come up with something reasonable if we felt that
>>> final by default with a "non-final" opt-in is too confusing.
>> 
>> I'm OK with finding other ways to do this than "non-final", though I think its
>> quite likely that the "non-*" convention will muscle its way in at some point
>> anyway (to name one example, classes that would be sealed by default will need
>> a way to say "not sealed"), so I don't want to put too much stock in
>> keyword-sticker-shock-avoidance.  (I actually think non-final is a pretty good
>> answer here; no one will be confused the first time they see it (they'll just
>> bikeshed that it should have been spelled μtable" or something like that.))
>> 
>> I'm less OK with saying "let's do immutable records now, and then figure out the
>> mutability story."
>> 
>> While some of the goodies for records will eventually filter down in some form
>> to classes (e.g., better ways to fill in the obvious defaults in constructors,
>> better ways to declare equals/hashCode), I also don't really want to count on
>> that; I'd like to do a complete record feature and then select the bits we want
>> to transplant to classes.
>> 
>> I guess the question that this particular sub-thread is looking for an answer to
>> is, which we dislike less: having to say final a lot, or having a new and
>> different default for mutability of record fields.  (Or something else.)