[RFC FS-1001 Discussion] String Interpolation redux

[dsyme]

This issue is used to track second round of discussions of F# RFC FS-1001 - "String interpolation"

Original discussion here: #6

[yatli]

Use this link to get permalinks and add comments here about the RFC content.

[yatli]

resolved

[cartermp]

One thing mentioned in the PR but not the RFC is interpolated verbatim strings. In C#, you need to do $@"..." today. They're thinking of extending this to also allow @$"...". So for F#, I'd say that we should support:

• $@"hello {name}"
• @$"hello {name}"
• $"""hello {name}"""

[yatli]

Should the embedded expressions be restricted to some subset of possible F# expressions to prevent abuse? If so, how are the expression restricted?

One proposal is to restrict to identifiers and dotted names.

I suggest the ast construct typedExprWithStaticOptimizationsBlock:

• It is r-value
• Can do arithmetics
• Can call a function
• Cannot define types
• Typed
• Can be a block, evaluating to the last expression
• Cannot be a let binding without in
• Cannot use open
• Can do member access

Additional considerations:

If we allow side effects, then we must be careful about the evaluation order.
C# translates interpolation to String.Format() and therefore the order is left-to-right.
We should comply with them.

[yatli]

An interesting feature in the revised RFC is that, if the printf family supports IFormatProvider and cultural formatting conventions, then both the conventional strings and the interpolation ones benefit from this.

I can think of two approaches here:

1. For all the printf family methods (sprintf, printfn etc.), create an additional method that first accepts a IFormatProvider. For example, suppose csprintf: IFormatProvider -> TextWriterFormat -> string , we can then have:

let fmt = csprintf <| CultureInfo("es-ES", false)
let str = fmt $"Current time is: {DateTime.Now}"

2. A composable approach is that we can extend PrintfFormat to hold IFormatProvider. In this way the printf family signatures remain unchanged, and we can introduce a function format: IFormatProvider -> PrintfFormat -> PrintfFormat to decorate the strings. So we have:

let fmt = format (CultureInfo("es-ES", false)) >> sprintf
let str = fmt $"Current time is: {DateTime.Now}"

[Tarmil]

One detail that is not mentioned in the RFC: escaping. By my understanding, format strings as proposed have two special characters that signal the start of an interpolation, % and {. Presumably they would be escaped as \% and \{?

[yatli]

@Tarmil, I've added a bit of information on escaping, in the RFC PR.
The C# interpolated string does not allow the escape sequence \{ and \}, so it's only possible via doubling, {{ and }}.
This is also the case for current F# spec char starter %, that \% is not allowed. Instead, use %%.

Edit:
interesting to see the difference: in C#, $"\x" raises CS1009: unrecognized escape sequence, but in F#, sprintf "\x" prints out \x

[Tarmil]

Nice, thanks! And good points, given these, doubling is better indeed.

[yatli]

I think the rationale behind these is that verbatim/multiline strings disable the \ escape sequences. We don't want to disable format spec escaping in that case.

[dsyme]

A composable approach is that we can extend PrintfFormat to hold IFormatProvider. In this way the printf family signatures remain unchanged...

I do like this approach. Perhaps an instance member to avoid API pollution:

let spanishPrintf (fmt: PrintfFormat<_,_,_,_>) = sprintf (fmt.WithFormatProvider(CultureInfo("es-ES", false))

[dsyme]

These do not agree.

sprintf "%O" null must continue to format as <null>

Besides that we can choose. I think that null should always format as the empty string for interpolated strings, and as <null> for any %O in printf format strings.

I've clarified this in the RFC

[dsyme]

I do like this approach. Perhaps an instance member to avoid API pollution:

I'll add this to the RFC via direct commit

[yatli]

Besides that we can choose. I think that null should always format as the empty string for interpolated strings, and as for any %O in printf format strings.

Makes sense. Consistency to both sides are maintained.

[charlesroddie]

Currently sprintf and derivatives use a reflection-based approach which is slow and AOT-unfriendly.

This RFC extends sprintf syntax.

Does this API entrench this problem or the API unrelated? If the sprintf logic were replaced with codegen in future, would having string interpolation increase the work? I'm not completely clear on whether efficient string formatting in F# would be based on an internal rewrite of sprintf or something completely new, perhaps based on https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1023-type-providers-generate-types-from-types.md .

[lukesdm]

Should the embedded expressions be restricted to some subset of possible F# expressions to prevent abuse? If so, how are the expression restricted?

If following the C# syntax, it might be more intuitive to mirror the C# behaviour as well i.e. allow similarly valid expressions. Perhaps offer some guidance in the docs as to intended best practices, but assume that devs will apply the same approach to code hygiene as in the rest of their codebase.

Depending on the restriction, this may exclude valid use cases

Yes - and trying to cater for these may lead to something like AngularJS templates, which can be a pain to deal with.

Also, there's a risk of divergence or extra maintenance when implementing new language features.

[yatli]

I'm trying to get a better understanding of your main concern and currently as I understand, I still think it's related: you have objection to (a single) string interpolation syntax to typecheck to multiple candidate types -- be it a PrintFormat, or FormattableString -- is that correct?

[charlesroddie]

you have objection to the string interpolation syntax to typecheck to multiple candidate types

Yes but this not the main point. We can make syntax adjustments to disambiguate these if desired.

The main point is that allowing interpolated string to give PrintFormat doesn't have a valid use case. It just allows people to write complex code to do a simple task in place of simple code.

[yatli]

I think the syntax adjustments are a bit noisy:

$F"okay"
$F"""still ok"""
$@F"?"
@$F"??"
@F$"???"

Plus it's redundant:

let (x: FormattableString) = $F"why do we need the F specifier here?"

And again, back to the PrintFormat case -- printfn only accepts PrintFormat, so either a plain string "..." or an interpolated string $"..." are typechecked as that. We already have the former, and the signature is not leaking anywhere (evaluates to unit), so why is this style making it more complex?

[charlesroddie]

back to the PrintFormat case

I think addressed exactly these points in my earlier comment. The signature is exposed to users (just hover over printfn), and in that sense, it does leak.

[yatli]

Understood. Thanks for your clarification.
I'm in oppose to these points, though.
Here is what I think:

• The printf family is composable, and more powerful than an interface that only accepts strings, so I think PrintFormat is logical and valid.
• Multiple typecheck candidates already exists for plain strings. And it makes code lean and mean without unnecessary noise. Adding that feature to interpolated string is a plus, and allows us to support 1) cultural string formatting, and 2) printf family.

[charlesroddie]

composable

Clearly print: string -> unit is the fundamental function used for composition here. For example printf = sprintf >> print.

Using printf for printing a string effectively involves gratuitous composition. You have a quasi-function (compiler-only) complexify:string->TextWriterFormat<unit> and printf:TextWriterFormat<unit>->unit and then use complexify >> printf instead of print. Effectively you are using complexify >> sprintf >> print: gratuitous composisition since complexify >> sprintf is the identity.

more powerful

Exactly the argument against using it. To do something simple it's better to use a simple and less powerful function than a complex and more powerful one.

[dsyme]

So to simplify the discussion it's safe to assume we're not going to add these.

let print = System.Console.Write: string->unit
let printn = System.Console.WriteLine: string->unit

Why?

• The decision to have printf/printfn as the primary F# ways to do console printing was made in F# 0.4 and we're not going to revisit that here.
• Adding a 3rd or 4th way to print a string isn't going to fly
• The ship has long since sailed on the "printf adds complexity" argument. This is definitely a valid criticism (I am hearing you @charlesroddie, and know the pain this mechanism has brought for UWP especially), but this RFC is not about revisiting that.

So to me, that pretty much means that this is supported:

printfn $"I say again {x} is one and %0.2f{pi} is pi".

That means interpolated strings support PrintfFormat. If we need to do added work to avoid beginners seeing TextWriterFormat or other complexity then we can do that. I'm happy with that as a resolution.

To do something simple it's better to use a simple and less powerful function than a complex and more powerful one.

Taken to its logical conclusion I think this would mean not adding string interpolation at all. We have .ToString() and + on strings.

[charlesroddie]

If we need to do added work to avoid beginners seeing TextWriterFormat

If what is seen is a printfn taking a string then that would be very good.

That would also allow

let s = $"I say again {x} is one and %0.2f{pi} is pi"
printfn s

Effectively printfn is overloaded, instead of $"..." being overloaded, which I think is much better. Similar to method overloads which are familiar.

[abelbraaksma]

let s = $"I say again {x} is one and %0.2f{pi} is pi"
printfn s

Just for my understanding, currently, this requires printfn "%s" s, right? Since s is resolved to be a string. Or would this feature (interpolated strings) allow s to be either a string, or a PrintfFormat<unit>? Would such magic introduce the ability to write let s = "foo" in printfn s? Or if, and only if, s is created using new interpolated string syntax?

[charlesroddie]

That's right. Yes it would allow let s = "foo" in printfn s.

[dsyme]

If what is seen is a printfn taking a string then that would be very good.

That's right. Yes it would allow let s = "foo" in printfn s.

There's no plan to change this as part of the RFC, I think it only complicates things to add a new form of overloading.

If we need to do added work to avoid beginners seeing TextWriterFormat

Here I was referring to the potential for simplifing the tooltip information given for Printf.

But TBH the feedback that seeing TextWriterFormat<'T> is hurting beginners is somewhat new to me. I'm pretty sure beginners just see printfn "hello world, 4 = %d" 4 and from that point on internalize that the thing after printfn is a format string.

[jbeeko]

'{' is very common in json so its use to signal the start of an interpolation will be inconvenient when working with json snippets because interpolation can be used in a chuck of json all '{' characters need to be doubled up like so:

$"""{{
    "InstructionId": "{timestamp}",
    "Type": "Payout",
    "Class": "ASAP",
    "From": {{ "Iban": "{ibanAccount1}",  "Name": "Account1" },
    "To": {{ "Iban": "{ibanAccount2}",  "Name": "Account2" },
    "Amount": {{"Value" : "0.59", "Currency": "EUR"},
    "SenderReference": "This is a client reference",
    "Description": "What will go on the bank statement"
}"""

Aside for needing to double up the '{' the result is also difficult to scan visually. Is is also obviously not valid json defeating any tools such as analyzers that may want to interpret it as json.

Of course any character chooses may be awkward in some domain ('<' would be a terrible choice in HTML). But perhaps it could be possible to specify the character used in some way. For example by putting it after the '$'. So
$["""{ "Iban": "[ibanAccount2]", "Name": "Account2" }"""
would be a valid interpolated string.

[dsyme]

'{' is very common in json so its use to signal the start of an interpolation will be inconvenient when working with json snippets

This is a reasonable observation. I'm not sure what the resolution should be though! For this RFC I guess we will just accept this limitation

[dsyme]

Notes from the design meeting we had three weeks ago are here: dotnet/fsharp#8907 (comment)

[abelbraaksma]

I just went through the latest version of the rfc, and I noticed that ${} is not explicitly forbidden (nor explicitly allowed). I mentioned it in my issue of yesterday.

I'm in favor of allowing it, though the current implementation disallows it.