On Oct 29, 2021, at 7:10 AM, Jim Laskey <james.las...@oracle.com> wrote: > > Given that an unprocessed templated string involves at least some deferred > evaluation, should we frame templated string parameters as being more like > method parameters (all parameters evaluated eagerly, left to right), or > should we treat them as lambda expressions, which may capture (effectively > final) variables from the environment, and evaluate the full parameters > expressions when they are needed?
If we take away that given, that deferred evaluation is “baked into” S.T., we are left (at least, I hope we will be left) with no natural constraints on expressions, just the usual practical ones. It would be comforting to me if I found that, in the end, all the “hole arguments” to S.T.’s are nothing more or less than garden-variety method arguments, with no special processing and no special restrictions. It is natural to want to forestall “bad form” uses of a new feature, and make parsing easier, and make it harder to write puzzlers, and all the rest. But there is a limit to such things, and eventually you have to let the user decide whether mis-use the language, according to the tastes of its designers. In any case, my design heuristics prefer few or no limitations on what can “go in the hole”, just as there are now few or no limitations on what can be passed as a method argument. Anything more restrictive feels like the Language Nannies have arrived. (Also, when I *do* use a Nanny, I prefer it to be wired into the IDE, not the language.) — John
