[records] SafeVarargs and canonical constructors

[Brian Goetz]

This seems a very practical place to land here.

On 12/29/2019 12:32 PM, Tagir Valeev wrote:
> I have a proposal on how to solve SafeVarargs problem:
>
> 1. Do not allow annotating record type with SafeVarargs
> 2. If the record type has explicit canonical/compact constructor, the
> heap pollution warning should be issued on the constructor, rather
> than on record header declaration
> 3. If explicit canonical/compact constructor is annotated with
> SafeVarargs, no warning should be issued.
>
> So if one has a record declaration with potential heap pollution, and
> want to declare that varargs are safe, they must explicitly add an
> empty compact constructor and annotate it with SafeVarargs. Given that
> this case should be extremely rare in practice, such an amount of
> boilerplate doesn't look too big to me. On the other hand, such
> solution requires less changes in Java (e.g. no need to allow
> SafeVarargs on types).
>
> What do you think?
>
> With best regards,
> Tagir Valeev.
>
> On Sat, Dec 28, 2019 at 1:10 PM Tagir Valeev <amaembo at gmail.com> wrote:
>> Hello!
>>
>> More questions about SafeVarargs:
>>
>> 1. If we have a compact constructor declared, should the warning be
>> issued at record header or at compact constructor declaration? To
>> suppress the warning should I annotate a record type or compact
>> constructor?
>>
>> 2. The same if explicit canonical constructor is declared.
>>
>> To me, it seems logical to put SafeVarargs at record type if compact
>> constructor is present (because the variable arity parameter is not
>> explicitly written in constructor declaration). However, if explicit
>> canonical constructor is declared, it seems better to require
>> SafeVarargs at constructor declaration, rather than a record
>> declaration. Or place it in either place (but not at both).
>>
>> What do you think?
>>
>> With best regards,
>> Tagir Valeev.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20191229/87e7e165/attachment.htm>