Update on String Templates (JEP 459)

[John Rose]

On 13 Mar 2024, at 15:22, John Rose wrote:

> … OVERLOADS …
>
> I don’t see (maybe I missed it) a decisive objection to overloading across ST
> and String, at least for some processing APIs.

Perhaps it is this:  A language processor API that takes STs and never Strings is making it clear that all inputs should be properly vetted, nothing taken on trust as a bare string.

Doing that MIGHT require a performance model which permits expensive vetting operations to be memoized on particular OCCURRENCES of inputs (not just the input strings viewed in and of themselves).

If that’s true, then I guess that’s support for Guy’s proposal: That STs (even trivial ones) should never look identical to strings.  Maybe they should always be preceded by a sigil $, or (per my suggestion) they should always have at least one occurrence of \{ inside, even if it’s a trivial nop.

I kind of like Guy’s offensive-to-everyone suggestion that $ is required to make a true ST.  Then it’s clear how the veteting APIs mate up with their vetted inputs.  And if $ is not placed in front, we surrender to the string-pasters, but at least the resulting true-string expressions won’t be accepted by the vetting APIs.