instance initializer
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu Sep 5 22:14:39 UTC 2019
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Tagir Valeev" <amaembo at gmail.com>, "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 5 Septembre 2019 23:26:34
> Objet: Re: Draft JLS spec for records
>> I don't think so. A compact constructor (or require initializer, as you propose)
>> could be not the only constructor. An instance initializer is convenient
>> because it's added to every constructor, regardless of whether it's compact or
>> not. So the new thing doesn't supersede the instance initializer and I see no
>> good reason to explicitly disable it.
> Vicente offered another reason why we might want to prohibit the instance
> initializer, if only out of expediency; it complicates the analysis of which
> fields are DA on all paths through the constructor (and therefore, do not need
> to be automatically initialized.) If you have a record:
> record Foo(int i) {
> { this.i = 0; }
> }
> then the canonical constructor has to see that `i` is always initialized by the
> static init, and therefore should be not initialized. Worse, if we have:
> record Foo(int i) {
> { if (tuesday) this.i = 0; }
> }
> then we have to issue a compilation error, since we have fields that are neither
> DA nor DU at the end of the initializer.
> None of this is impossible to do, of course; it's just not clear whether it's
> worth it, given the limited utility of instance initializers in records
> (because we've already banned instance fields.)
If we want to fix that with an the analysis, it will have to work on user-written code mixed with generated code,
it doesn't seem to be a good idea.
so it's Ok to not support instance initializers in record.
Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190906/2d6cc2b4/attachment.html>
More information about the amber-spec-experts
mailing list