- "That's 3 issues in 8 minutes." "That's an LDM record!"
- "Back to serious stuff. Raw string literals. Because raw is better for digestion"
Back when the linked comment on #39 was raised, we had an internal email chain discussing changing the implementation of == to move the
reference equality short-circuit down to the strongly-typed Equals implementation. We came to the conclusion that instead of moving the
check we should duplicate it, to ensure that == still behaves correctly for null, but we never followed up on that conclusion. Today,
we confirmed that we do indeed want to do that, and update the C# compiler to generate this better version of equality.
We'll do this. dotnet/roslyn#51136 tracks following up on that work.
Our last discussion on the namespace directive had one open question left: should we allow them in combination with top-level statements? We had an internal email chain on this topic since then, and came to the conclusion that we should disallow this combination. There's a couple reasons for this:
- We think the namespace directive is confusing here. It looks like a statement, but the rest of the statements on the top-level don't introduce a new scope.
- It is easier to remove an error later if we decide that it's too restrictive. If we allow it, we'd have to support it forever.
- Users might expect to be able to put a namespace before those top-level statements and change the namespace the implicit
Mainis generated into.
Decision upheld. Top-level statements are not allowed in combination with file-scoped namespace directives.
Our last discussion on global usings had us split right down the middle on whether to make global usings a C# syntax feature, or a command-line switch to the compiler, with a razor-thin majority leaning to C# syntax. In order to make progress here to begin implementation, we again took an internal email chain to discuss this further. This conversation drew a few conclusions:
- Neither a a command-line switch nor C# syntax would prevent a source-generator from providing their own set of usings, but the switch would prevent the source-generator from dynamically providing this, it would have to be predefined in props/targets file in the generator nuget package.
- We really need to be considering the experience when using
dotnet, notcsc. The SDK passes 182 parameters to a build of a simple hello world application today. It's very unrealistic to base scenarios on callingcscdirectly. - For the base templates, such as as a console app or a default ASP.NET application, this choice doesn't really affect the files the
templates drop down. In either case, the usings will be hidden. For more complicated templates, this choice changes whether the template
drops a
GlobalUsings.csfile, or fills in a property in the template csproj. In either case, the template has really moved beyond a single-file program, so the difference isn't huge. - We've had a number of requests over the years for global aliases, and a C# syntax will fit in nicely with such a feature.
Given the need to start implementing here and the thin majority that prefer C# syntax, we will start investigation and implementation on the C# syntax version, with a speclet forthcoming later this week.
This feature will add symmetry with tuple patterns/deconstruction, which is desirable. There is some potential parsing challenges, as several of the examples look like a block with a labelled statement inside it and will need some tricky work to ensure disambiguation works.
To the backlog. We like the idea and think there's a way to get it into a form we like, but can't commit to it right now.
This is a simple enough change and we've had a few complaints about the behavior and inability to seal. As an alternative, we could
design a parallel ToString implementation for records that the base type in a hierarchy will call into, which would be a minor behavior
change from C# 9 as released. However, this would be complicated, and sealed is the keyword to tell consumers "No really, this is the
final version of this behavior, you can't change it."
We'll put this in Any Time to promote community contributions for this small feature, but if no one picks it up we will likely put in a bit of effort to get it into C# 10.
The title of this issue is a bit of a misnomer, as the proposal actually extends to all types, not just tuples. We've also looked at a
broader proposal recently in conjunction with the global using statement feature, which would allow things like
global using MyDictionary<TValue> = System.Collections.Generic.Dictionary<int, TValue> and other similar work. It seems like we want
to make some improvements in the alias and using area, and we should consider doing a subset of that larger proposal now in the same
fashion that we've continuously shipped incremental updates for patterns.
Triaged into the working set. We want to make a general using improvement push in 10, and have a goal of at least doing this much for alias improvements in this release.
There are a number of potentially contentious design decisions in this area, but we intentionally tried to steer away from them today and limit to just the general concept. There are many scenarios for embedding other languages into C#: XML, JSON/Javascript, C#, and more. In many of these languages, " and ' are not interchangeable, so anything with a " in it is painful in C# today. We also thing that interpolation in these strings is important, as these embedded code scenarios are often used for templating. There is potential work around a way to specify what character sequence defines the interpolation holes, but we did not go into details or specifics here.
Into the Working Set. There's a bunch of design questions that we'll need to spend some time working on.
This is a minor convenience issue that has come up a few times for users, but has potential implementation nastiness with disambiguating
whether nameof is a method or a nameof_expression. Given the minor benefit and the potential implementation concerns, we're concerned
about doing this unless we decide to make nameof a non-conditional keyword.
Rejected. If we ever make the change to make nameof not a conditional keyword and can simplify the binding here, then we can bring this
back, but until that point we will leave this as is.
As the language is specified today, compliant C# compilers have to emit certain overflow conversions and then roundtrip those conversions back to the original representation. This is inefficient and a small spec change will produce no observable semantic difference, while allowing the compiler to emit better code.
Accepted into the working set.
This is something that patterns are very verbose about today, and it's a syntax we've previously discussed as a potential shorthand to reduce the boilerplate. We could also potentially extend this idea to object initializers, but don't want to tie that to this proposal.
Accepted into the working set.