Records -- current status

[Brian Goetz]

And, then when we have non-nullable types, you can write:

     void foo(!final String! s)

and users will think its a few form of brackets.

On 3/29/2018 3:25 PM, Guy Steele wrote:
> 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
>
> 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.)
>>