The .NET SDK 8.0.100 adds various new diagnostics. Some of these relate to new language features in C# 12.0, and some are just part of the ongoing tendency for the SDK to notice ever more issues.
This updates the code to use C# 12.0 collection expressions except in one case: we aren't currently big fans of IDE0305, which wants to transform all uses of x.ToArray() to [.. x]. This seems a little obscure. Possibly it will seem more natural in a few years when we're used to seeing collection expressions. Or possibly not—use of spreads in these expressions might be a less mainstream technique.
After some deliberation we've also elected to disable IDE0290, which wants us to use primary constructors. Although there are some cases where its suggestions seem like a clear improvement, in some they are not. In particular, when types have multiple constructors but the diagnostic has determined that use of this(...) means its able to designate one as a primary constructor, it often just looks a bit odd. The decision to use this(...) is often an implementation choice, and the constructor elevated to be the 'primary' one often looks a bit arbitrary as a result. Unless and until some way of making this rule more selective can be found, we are going to leave it switched off.
The .NET SDK 8.0.100 adds various new diagnostics. Some of these relate to new language features in C# 12.0, and some are just part of the ongoing tendency for the SDK to notice ever more issues.
This updates the code to use C# 12.0 collection expressions except in one case: we aren't currently big fans of IDE0305, which wants to transform all uses of
x.ToArray()to[.. x]. This seems a little obscure. Possibly it will seem more natural in a few years when we're used to seeing collection expressions. Or possibly not—use of spreads in these expressions might be a less mainstream technique.After some deliberation we've also elected to disable IDE0290, which wants us to use primary constructors. Although there are some cases where its suggestions seem like a clear improvement, in some they are not. In particular, when types have multiple constructors but the diagnostic has determined that use of
this(...)means its able to designate one as a primary constructor, it often just looks a bit odd. The decision to usethis(...)is often an implementation choice, and the constructor elevated to be the 'primary' one often looks a bit arbitrary as a result. Unless and until some way of making this rule more selective can be found, we are going to leave it switched off.