csharplang/meetings/2022/LDM-2022-04-11.md

C# Language Design Meeting for April 11th, 2022

Agenda

1. Relax restrictions on braces on raw interpolated strings
2. Self-type stopgap attribute

Quote of the Day

• "Maybe we should introduce the £ symbol for interpolated strings"

Discussion

Relax restrictions on braces on raw interpolated strings

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

After some initial usage of raw string literals, we wanted to revisit the reasoning behind limiting the number of {'s just before an interpolation hole, as it came up as confusing to explain to several users. The idea is that, before an interpolation hole, users would be able to specify as many { characters as they wanted, and the compiler would only treat the inner {'s that make up an interpolation hole as the delimiters. This would allow $""" {{0}} """ to be a string with the content {0}. There are, however, some potential issues with this:

1. In 99% of cases a { in an interpolated raw string literal with a single $ is not permitted, as such a character denotes the start of an interpolation hole. Relaxing this restriction would be odd, as { {0} would be disallowed, but {{0} would be allowed.
2. The rules as is are consistent with the rules for the quotes, and changing the rules would require that users understand multiple sets of rules.
3. $"{{expr}}" has meaning today, as a string with the content of {expr}. If we permitted $"""{{expr}}""" to compile, it might end up confusing users who expect it to have a similar meaning to existing interpolated strings.

Conclusion

We will keep the restriction as is.

Self-type stopgap attribute

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

As an attempt to prevent simple user errors with our new numeric interfaces, and preserve the potential to use self types in those interfaces in a future where we add support for them, we considered an attribute that could be applied to type parameters to enforce that the type parameter can only be substituted with the containing type, or a type parameter that is also attributed with the same attribute. We quickly started delving into the nitty gritty of the implementation: should we allow it on abstract classes, for example, or be more opinionated with where the parameter so attributed must occur? However, we came to the conclusion as we were doing this that we were creating GenericMathSelfTypeAttribute, not a generalized SelfTypeAttribute. We don't have the broader understanding of the usage of self-type type parameters of the entire ecosystem to attempt to rush in a generalized protection feature here, and think the space is more appropriate for an analyzer in the BCL to enforce the rules that matter for the interfaces in question.

Conclusion

Rejected. We will look at a BCL analyzer to enforce the rules they want to enforce for these interfaces.