Support `DefaultInterpolatedStringHandler`

[vzarytovskii]

Support DefaultInterpolatedStringHandler

the suggestion was originally posted in https://github.com/dotnet/fsharp (https://github.com/dotnet/fsharp/issues/12069) by @xperiandri

I propose we support DefaultInterpolatedStringHandler in F#.

The existing way of approaching this problem in F# is using default interpolated strings.

Pros and Cons

The advantages of making this adjustment to F# are

• Unification with what Roslyn has.
• Faster interpolated strings.

The disadvantages of making this adjustment to F# are ...

Extra information

Estimated cost (XS, S, M, L, XL, XXL): L

Affidavit

Please tick this by placing a cross in the box:

• [x] This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• [x] I have searched both open and closed suggestions on this site and believe this is not a duplicate
• [x] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

• [x] This is not a breaking change to the F# language design

For Readers

If you would like to see this issue implemented, please click the :+1: emoji on this issue. These counts are used to generally order the suggestions by engagement.

[cartermp]

This is handy in code instrumentation scenarios (e.g., OpenTelemetry) where you want as little overhead as possible but still want to do a little string formatting for messages on constructs (e.g., a small structured Span Event on a TelemetrySpan).

[dsyme]

Yeah, it's solving some real problems. But my goodness I find the adhoc nature of these C# solutions to these problems really problematic (e.g. the attributes on parameters).

As an aside, one thing I'm aware of is that there's a similarity between computed list expressions and computed string expressions (aka string interpolations)

• computed list expressions ideally write imperatively to a list collector
• computed string expressions ideally write imperatively to a string collector

It would kind of be nice if there was more symmetry to this, e.g. why can't we use for loops in string interpolations, e.g.

$"""abc {for x in xs do yield x; yield ";"} def"""

or implicit yield:

$"""abc {for x in xs do x; ";"} def"""

and conditionals

$"""abc {if today() then header} def"""

and pattern matching

$"""abc {match day with Monday -> header | _ -> footer } def"""

Anyway it totally makes sense to emit interpolated strings to a collector, and to sort out the conditional nature of the emit.

[realparadyne]

Could this become an interop pain point (or even a blocking issue) if people start making libraries with methods that make use of custom InterpolatedStringHandlers for some parameters but no longer expose plain String alternative overloads?

I would love to see further development of F# string interpolation for higher performance, greater flexibility (I've already seen a C# attempt at using a custom handler to invert it into a scanf() type of function) or even just some more optimisation for simple cases e.g.

$"""value: {stringValue}"""

Which doesn't need all the full string formatting but just some fast concatenation of two strings.

[Tarmil]

We could even imagine full-blown type-provider-like code generation that would use the string fragments and quotations of interpolated values at compile time to generate arbitrary code, not necessarily calls to specific methods on a builder like InterpolatedStringHandler does. For example parsing HTML at compile time to compile something like this:

html $"""<div id="test">Hello, {name}!</div>"""

into the equivalent of Fable/WebSharper/Bolero/etc function calls:

div [ attr.id "test" ] [ text "Hello, "; text name; text "!" ]

In fact, I can say for sure that Bolero would be able to provide better performance using the former than it currently does with the latter. Of course this would be an XXL dev effort 😄

[cartermp]

@realparadyne

Could this become an interop pain point

yes and no. Yes, insofar as there will be new methods in .NET 6 (not many) that take on in as a parameter, and an F# consumer would need to construct an explicit instant of DefaultInterpolatedStringHandler as a parameter. But the answer is a "no" insofar as no existing APIs are being changed to use this instead of string parameters.

[baronfel]

There are ~1000 uses of DefaultInterpolatedStringHandler on github code search, and the areas I see commonly are:

• logging
• http frameworks
• tracing/telemetry
• Game engines?
• generated API clients that want to be as low-impact as possible

The runtime usages are also very low-level on StreamWriter et al, so writing to all kinds of streams could become more performant with the single feature.

[Xyncgas]

Could this become an interop pain point (or even a blocking issue)

Blazor kinda figured out mixing C# with html

html $"""

Hello, {name}!

"""

That's awesome, I can make a lot of html using this approach, each generated functionally presenting information of their domain, I put them all in the same page on my website, regenerate functionally and in parallel

[vzarytovskii]

Put an approval on it, since there's a general consensus that addition makes sense. Needs an rfc though.

[charlesroddie]

Some benchmarks for HW: let world = "world" in $"hello {world}" with current and some alternative implementations and TT: let two = "two" in $"{two} + {2} = {4}"

https://github.com/charlesroddie/BenchmarksFsharp/tree/InterpolatedStrings

Method	Mean	Error	StdDev	Gen0	Allocated
InterpolatedStringCurrentHW	84.04 ns	1.337 ns	1.044 ns	0.0219	184 B
StringFormatHW	37.14 ns	0.545 ns	0.483 ns	0.0057	48 B
StringBuilderHW	19.99 ns	0.430 ns	0.442 ns	0.0181	152 B
DefaultInterpolatedStringHandlerHW	41.65 ns	0.713 ns	0.596 ns	0.0057	48 B
InterpolatedStringCurrentTT	195.90 ns	3.704 ns	3.465 ns	0.0458	384 B
StringFormatTT	81.88 ns	1.578 ns	1.549 ns	0.0124	104 B
StringBuilderTT	28.69 ns	0.626 ns	1.191 ns	0.0181	152 B
DefaultInterpolatedStringHandlerTT	49.24 ns	0.988 ns	0.876 ns	0.0057	48 B

Overall StringBuilder is the fastest, but DefaultInterpolatedStringHandler allocates the least. There appear to be performance costs of DefaultInterpolatedStringHandler relative to StringBuilder, at least for the typical case where custom formats are not needed.

I think a move to StringBuilder would be a good first step and would get the majority of the benefit.

Any move to DefaultInterpolatedStringHandler would build on that.

DefaultInterplolatedStringHandler is also dotnet6 so there would need to be a fallback implementation with StringBuilder anyway for netstandard2.0, or alternatively DefaultInterplolatedStringHandler can be a replacement when FSharp no longer supports netstandard2.0.

[realparadyne]

If it could iteratively optimise the interpolation then constant strings could be interpolated in at compile time, reducing the number of elements to concatenate. Speaking of which, if at the end all that's required is to concatenate some constant strings and some dynamically produced strings (up to 4 I think?) there are a bunch of overloads to String.Concat() that should be faster than using StringBuilder and only allocate for the resulting string.