New candidate JEP: 430: String Templates (Preview)

[Steve Barham]

> On 20 Sep 2022, at 19:10, Mark Reinhold <mark.reinhold at oracle.com> wrote:
> 
> https://openjdk.org/jeps/430

Really looking forward to this feature, and would echo the feedback about using \{ } to delimit expressions being a great way to disambiguate template strings from strings proper.

One question I have is around the generality of the JLS change required to handle processors and templates. 

Application of a template processor feels an awful lot like application of a Function<>; the call effectively has type Function<TemplateProcessor, TemplatedString, R> which for the specific types of TemplateProcessor and TemplatedString are blessed by the language, such that they support invocation via a dot operator. 

If in the future we have language support for application of Function<> interfaces (and associated overloads / parameterisations, ye even unto Function22), is the thinking that it would use a similar mechanism - i.e. STR.”Hello \{name}” is revealed to have been STR.apply(“Hello \{name}”) all along? 

If so, it feels like there might be an uneasy difference between 1-ary and n-ary parameter lists, in which we could have STR.”Hello \{name}”, but would need foo.(10, “bar”) for application with multiple parameters. 

Handling application via brackets rather than dot (or via dot _and_ brackets) would seem to tidy things up a bit - we still have a special case for the moment in which TemplateProcessor can be invoked with a TemplatedString, it just looks like STR(“Hello \{name}”) or STR.(“Hello \{name}”), but has the benefit of leaving the application syntax open later for the more general case of n-ary application. 

Cheers,

Steve