C# Language Design Meeting for August 25th, 2021

Agenda

1. Interpolated string handler user-defined conversion recommendations
2. Interpolated string handler additive expressions

Quote of the Day

• "Let's have a bio break until next Monday" [LDM proceeds to end an hour early]

Discussion

Interpolated string handler user-defined conversion recommendations

https://github.com/dotnet/csharplang/issues/5077

We think the scenarios such a recommendation would serve are extremely small, as we don't expect the vast majority of users to use handler types directly. Instead, they will create interpolated string literals and the compiler will generate the handlers for the user. Additionally, while there's often not much protection, we're concerned that some cases without string overloads for methods would cause forgetting a $ to have unintended behavior, particularly when combined with other operators such as +.

Conclusion

Recommendation rejected. We will not make strong statements on whether users should define implicit conversions from string.

Interpolated string handler additive expressions

https://github.com/dotnet/csharplang/issues/5106

The root of this question is how we apply order of operations and the associative and commutative properties to parenthesized interpolated string addition expressions. For example, given the following code: $"...." + ($"...." + $"...."), order of operations would suggest that we evaluate the components of part 1, then part 2, then part 3. Then we combine parts 2 and 3, and finally combine the results of 1 with the results of 2+3. Interpolated string handlers can't operate in this "combine the latter bits then prepend the former" mode. However, by the same token the side effects of this combination are mostly unobservable, and we're very leary of having parentheses be ok in some scenarios but not in others. This means that we have 2 options:

1. Make parentheses always break the magic. A parenthesized interpolated string is just a string.
2. Make parentheses not matter. An expression composed only of additive expressions, interpolated string expressions, and parenthesized expressions counts as single interpolated string for the purposes of handler conversions.

Option 1 forces us to try and answer awkward questions such as "What does CustomHandler c = ($"" + $""); mean?", and we don't like how it makes parentheses less transparent than they are currently. Therefore, we'll go with option 2. As part of this, we'll also allow nullable suppression operators to be interspersed, as they are similarly "transparent" and shouldn't have any impact on the final code.

Conclusion

Allow parentheses and nullable suppression operators anywhere in the interpolated string additive expression chain.