fsharp
Support `DefaultInterpolatedStringHandler`
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.
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).
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.
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.
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 😄
@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.
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.
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
Put an approval on it, since there's a general consensus that addition makes sense. Needs an rfc though.
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.
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.
Agree that a StringBuilder version is a great improvement already, and thus a fine starting point. One thing your benchmarks don't make use of (because it doesn't matter for such short strings) is the fact that we can typically estimate the minimum capacity the builder needs to allocate, sometimes even the exact length, which will give us ever so slightly more performance.
