Hello!
I think that deferred semantics could be confusing and it provides too
little benefit to justify its use. For example:
DebugLogger."The number of objects: \{counter.incrementAndGet()}";
We saw a number of bugs like this in assert statements. The unpleasant
thing is that in unit-tests
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "Jim Laskey" , "amber-spec-experts"
>
> Sent: Vendredi 29 Octobre 2021 20:26:28
> Subject: Re: [External] : Re: Are templated string embedded expressions
> "method parameters" or "lambdas"?
>> Do we really need to
Do we really need to support the second case at all ?
Yes :)
Instead of
"Hello \{name()}"
it can be written to something like
() -> F."Hello \{name()}"
That deprives your callee of the opportunity to choose the formatter for
you. Whoops, now the feature is way less expressive.
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax" , "Jim Laskey"
> Cc: "amber-spec-experts"
> Sent: Vendredi 29 Octobre 2021 19:20:20
> Subject: Re: Are templated string embedded expressions "method parameters" or
> "lambdas"?
>> For me, "deferred execution" is not the
For me, "deferred execution" is not the right way to think about the
sub expressions of a templated string.
I think there really are two (related) cases here.
The first (and more common) case is when you provide a formatter object
directly:
Foo f = F."Hello \{name()}"
Here, there
> From: "Jim Laskey"
> To: "amber-spec-experts"
> Sent: Vendredi 29 Octobre 2021 16:10:54
> Subject: Are templated string embedded expressions "method parameters" or
> "lambdas"?
> For our early templated string prototypes , we restricted embedded expressions
> to just basic accessors and basic
For our early templated string prototypes, we restricted embedded expressions
to just basic accessors and basic arithmetic. The intent was to keep things
easy to read and to prevent side effects. Over time, we began thinking this
restriction was unduly harsh. More precisely, we worried it that
