New candidate JEP: 430: String Templates (Preview)

[Brian Goetz]

Thanks for the thoughts.  Some comments inline.

> Though I like the general idea behind this JEP. I have some concerns
> with it in its current form:
>
> 1. Might be a personal preference, but I find the
> `TemplateProcessorExpression . Template` syntax bizarre.

We knew that at least one out of the 10M Java developers would loudly 
proclaim "I hate the syntax", so congratulations, it's you :)   New 
syntaxes are risky; people are used to "${foo}" in other languages, and 
this is new and different, and sometimes different is scary.  But, it 
wasn't picked out of a hat; a good deal of thought has gone into this, 
and so while it may seem weird now, give it a year and I suspect it will 
not seem so odd.  (In any case, amber-dev isn't the forum for syntax 
discussions, so let's leave this here.)

> 2. The `TemplatedString` is more complicated than necessary. It is not
> obvious by just looking at it, how to
> implement a `TemplateProcessor`.

Perhaps, but the ratio of people who *use* TemplateProcessor to those 
who *write* it is probably 1,000 to one or more.  And there are a lot of 
hidden requirements that have been sussed out as a result of writing not 
only the obvious processors, but some less common ones as well.  So what 
seems unnecessary to you may simply be that you are thinking of simpler 
use cases.

> 4. Last time I saw, the compiler generated a new class for each
> `TemplatedString` instance

You are aware there is a class generated per lambda / mref too, right?   
And yet no one is saying "Lambda translation is too heavy."  (There are 
also options available to improve the translation, but it's still early 
for that game.)