From 7d1157b445990c8757381344ebc3de7f33f61726 Mon Sep 17 00:00:00 2001 From: Fredric Silberberg Date: Thu, 25 Mar 2021 10:49:29 -0700 Subject: [PATCH] Added LDM Notes for March 24th, 2021. --- meetings/2021/LDM-2021-03-24.md | 70 +++++++++++++++++++++++++++++++++ meetings/2021/README.md | 23 ++++++----- 2 files changed, 83 insertions(+), 10 deletions(-) create mode 100644 meetings/2021/LDM-2021-03-24.md diff --git a/meetings/2021/LDM-2021-03-24.md b/meetings/2021/LDM-2021-03-24.md new file mode 100644 index 0000000..5a1d08b --- /dev/null +++ b/meetings/2021/LDM-2021-03-24.md @@ -0,0 +1,70 @@ +# C# Language Design Meeting for March 24th, 2021 + +## Agenda + +1. [Improved interpolated strings](#improved-interpolated-strings) +2. [`field` keyword](#field-keyword) + +## Quote of the Day + +- "We all want to be happy" + +## Discussion + +### Improved interpolated strings + +https://github.com/dotnet/csharplang/issues/4487 + +Today, we looked at one of the open questions in improved interpolated strings, conditional evaluation of the interpolated +string holes. The proposal today allows the interpolated string builder to return `false` from creation or from any `TryFormat` +methods, which short-circuits evaluation of any of the following interpolation holes. This has some pros and cons: + +* Pro: Interpolation holes can be expensive, and if they don't need to be executed it gives an easy way to achieve semantics +that people often do with lambdas currently. +* Con: This is "invisible" to the user. There isn't a way, looking at an interpolated string expression as an argument to a +method, to tell whether the holes in this string will be conditionally-evaluated or not. + +This conditional evaluation can have visible impacts when the interpolated string expression has side-effects. For example, +a conditionally-evaluated string won't have its holes impact definite assignment, because we can't be sure that the expressions +were evaluated. Further, due to the way the proposal is written, upgrading to a new version of a library could change the +semantics of existing code, as the library author could introduce a new overload that the interpolated string prefers, introducing +conditional evaluation of what used to be unconditionally-evaluated code. While library upgrades can always introduce behavior +changes in a user's code (introducing a new instance method that is preferred over an extension method, for example), this would +be expanding such concerns. + +We considered whether to have some syntax marker to indicate that "the interpolated string expression holes will be conditionally +evaluated", such as putting a `?` in the hole (like `$"{?name}"`). While this syntax calls out that conditional evaluation is +occurring, we're concerned that it leans too far into making new language features obvious. We'd need to start shipping analyzers +that ensure that users are using this syntax where possible, and it could become another pitfall of "make sure you add this syntax +for maximum performance." + +Finally, we looked at whether we could investigate a broader feature around lazily-evaluated arguments. Today, users often use +lambdas to defer this type computation. We're concerned by building a feature like this on lambdas, however, because of the +implicit allocation cost here. If we make advances in this space later, we can look at incorporating those advances at that point, +but we feel that we can move forward with conditional evaluation at this point. + +#### Conclusion + +We will have conditional evaluation of interpolated string holes without a special syntax for calling this out. + +### `field` keyword + +https://github.com/dotnet/csharplang/issues/140 + +We looked at how the `field` identifier will be resolved inside a property, and what exactly will indicate to the compiler that the +property should have a backing field generated for it. The proposal calls for resolving `field` to the backing field when there is +no other identifier named that in scope. We thought about a few alternatives: + +* Could we make `field` _always_ a contextual keyword in property bodies, gated by target language version? We made a bigger break +with `record` type names, but it was a very different break. `record` was used as a type name, which are by-convention PascalCase +in C# programs. Here, we'd be breaking `field` as an identifier, which is much more common and fits in with standard C# naming +practices. +* Could we use a `__` name? Identifiers with a `__` are reserved by C#, so we can use one without breaking anyone. However, `__` +names are not common, only used for things that aren't common practice in C# (such as `__makeref` or `__arglist`). +* Could we take a page from VB's book, and introduce a `_PropName` identifier? While it still has a potential conflict with class +fields, the conflict should be much smaller, and theoretically resolving the ambiguity could be as easy as deleting the class field +(provided we get the naming right), whereas a class `field` identifier could be entirely unrelated to the current property. + +#### Conclusion + +We'd like to explore the last 2 proposals a bit, and come back to the LDM with a fleshed out proposal after some thinking about it. diff --git a/meetings/2021/README.md b/meetings/2021/README.md index 045f164..beff5ce 100644 --- a/meetings/2021/README.md +++ b/meetings/2021/README.md @@ -2,9 +2,10 @@ ## Schedule ASAP +- Open questions in interpolated strings (Fred): https://github.com/dotnet/csharplang/blob/main/proposals/improved-interpolated-strings.md + ## Schedule when convenient -- List pattern open questions (Fred): https://github.com/dotnet/roslyn/pull/49080#issuecomment-777026383 - List pattern on enumerables (Julien): https://github.com/dotnet/csharplang/pull/4575 ## Recurring topics @@ -35,19 +36,21 @@ - Parameterless struct constructors (Chuck): https://github.com/dotnet/csharplang/blob/main/proposals/parameterless-struct-constructors.md - Async method builder override (Julien/Stephen): https://github.com/dotnet/csharplang/blob/main/proposals/async-method-builders.md -## Mar 24, 2021 - -- Interpolated string open questions (Fred): https://github.com/dotnet/csharplang/pull/4486 -- `field` in auto-properties (Cyrus) - -## Mar 22, 2021 - -- *Design review* - # C# Language Design Notes for 2021 Overview of meetings and agendas for 2021 +## Mar 24, 2021 + +[C# Language Design Notes for March 24th, 2021](https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-03-24.md) + +1. Improved interpolated strings +2. `field` keyword + +## Mar 22, 2021 + +- *Design review* (No notes published) + ## Mar 15, 2021 [C# Language Design Notes for March 15th, 2021](https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-03-15.md)