JEP 430 String Templates, some weird scenarios feedback

[Brian Goetz]

More generally, any variable that is today used in string concat, 
String::format, or println is a candidate for use in a template.  Many, 
many of these will not be effectively final.

On 6/16/2023 4:23 PM, Remi Forax wrote:
> ----- Original Message -----
>> From: "Stephen Colebourne"<scolebourne at joda.org>
>> To: "amber-dev"<amber-dev at openjdk.org>
>> Sent: Friday, June 16, 2023 10:56:43 AM
>> Subject: Re: JEP 430 String Templates, some weird scenarios feedback
>> On Thu, 15 Jun 2023 at 23:49, Brian Goetz<brian.goetz at oracle.com>  wrote:
>>> On 6/15/2023 6:01 PM, Anatoly Kupriyanov wrote:
>>>
>>> I understand why it works like that but it still causes some confusion to me, at
>>> least it should be somehow documented:
>>>
>>> var val = 1; var template = RAW."val = \{val}"; assert
>>> template.interpolate().equals("val = 1");
>>> val = 2; assert template.interpolate().equals("val = 1");//weird
>>>
>>>
>>> Yes, a template closes over values, not variables.  We could adopt the same
>>> constraint as we do with lambdas / inner classes -- require that any referenced
>>> variables be effectively final -- but this would likely be quite restrictive
>>> given the typical use cases for string templates.
>> FWIW, the example here pushes me to encourage you to adopt effectively
>> final - and the parallel with lambdas means that no one will be
>> surprised by choosing effectively final for templates.
>>
>> I am surprised by the claim that "typical use cases" make this
>> restrictive. Can you expand? Given that the value is captured not the
>> variable, it is hard to imagine use cases where effectively final
>> would be problematic. If there are problematic use cases, perhaps it
>> would be better to add a language change that gives the developer more
>> control over effectively final (various options available),
> It will not be convenient for all template processors used for logging/printing.
>
>    LOGGER.trace()."\(thisVariableMustNowBeEffectivelyFinal)";
>
>> Stephen
> regards,
> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230616/b83198e6/attachment-0001.htm>