[External] : Re: StringTemplates deferred evaluation

[Ron Pressler]

> On 17 Mar 2024, at 23:16, Justin Spindler <justin.spindler at gmail.com> wrote:
> 
> C#s approach handles both cases.  It's not just interpolation, the formatting of the string is handled by the consumer of the FormattedString or by the custom interpolation handler.  Both work with the raw string fragments and embedded values and can safely construct the string for the given use case.

The problem with that design is that a template could be interpolated *implicitly* when assigned/passed to a string (and worse: interpolation is *preferred* when the template is assigned to a var). Given how dangerous interpolation is, this is something we’d like to avoid; any utility that interpolation has is easily offset by its considerable risk. So any interpolation feature — be it in the core library or perhaps in some future language feature — should be explicit.

> 
> C# did add custom interpolation handlers in a later release, based of the feedback from the logging use case.  If Java wants to take a few cycles to see how the feedback shakes out to see whether it's worth considering, that's fine.  The most I might ask is that the current design doesn't preclude such enhancements, and from what I can see it wouldn't.

Right, although a feature that allows library code to control the evaluation of Java expressions would need to be sufficiently justified as solving a significant and common problem. That there are situations where deferring evaluation of expressions would be useful does not mean that it’s a serious-enough problem to merit a solution in the language, let alone one with subtle and non-obvious implications such as library-controlled evaluation. Not every problem deserves a language solution.

— Ron