Support `DefaultInterpolatedStringHandler`

[vzarytovskii]

Support DefaultInterpolatedStringHandler

the suggestion was originally posted in https://github.com/dotnet/fsharp (dotnet/fsharp#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:

• This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• I have searched both open and closed suggestions on this site and believe this is not a duplicate
• 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:

• 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 👍 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.