JEP 430 String Templates, some weird scenarios feedback

[Remi Forax]

----- 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