Are you suggesting that these design decisions make it through the entire process and into the language without the feature bringing a clear advantage in its use case? What would you say are the worst two or three of these C# features approved in the last decade?

Let’s assume for the sake of argument that you are correct though. The Roslyn compiler diagnostics are second to none, and pretty much any of these features will have corresponding analyzers to help remove some of that confusion, with documentation links being automatically provided if used incorrectly.

These guys aren’t writing feature proposals the way you write comments.

You’re comparing the effort of a mainstream language design proposal to a pseudonymous internet comment, wow, just wow.

Do you truly know real software developers using any these new features? I must not be working anywhere cool because I’m always having to explain what they mean in code reviews.

Imagine writing a full C# compiler in 2024, imagine if one possibly could with all these different features in this big big language.

> Are you suggesting that these design decisions make it through the entire process and into the language without the feature bringing a clear advantage in its use case?

I’m suggesting they don’t end up being adopted by enough people to be convincing. To me that leads to the shared problem with cpp, feature bloat. Multiple ways of achieving the same thing.

Since you asked, these are the three off the top of my head.

1. Init keyword is strange, why specify an accessor that only seems to apply during initialization? We already have read only for constructors. I always felt initializing objects with brackets (whatever they hell they call it) was something meant for more casual code where assignment isn’t enforced or restricted.

2. Switch expressions are ridiculous. They can get hard to read, alienating non C# programmers who come from C styled backgrounds, part of what made this language successful to begin with. They seem more like yet another syntax sugar we have to learn. And to your Roselyn comment, a language shouldn’t be dependent on Roselyns analysis to actually be usable to the general public. That is not what I’d call a cross platform language, that’s a monopolistic one where Windows/Visual Studio is the only place a not .net fanatic such as yourself can easily get work done.

3. Nullable Reference Types further over complicates what used to be a simple system of reference and value types. On top of the already head scratching nullable value types which made people question why they initially moved away from javas only reference type concept to begin with.

Slightly off topic but we have at least 3 ways to define record types: tuples, structs, and now records. I actually do like record types but unfortunately now existing code bases are polluted with the former. The point I’m trying to make in this last statement is I feel they aren’t careful enough with their proposals. They got it right with records, but look what they brought us along the way.

> Do you truly know real software developers using any these new features? I must not be working anywhere cool because I’m always having to explain what they mean in code reviews.

If you mean 9-5 devs, I am not even afforded the luxury of working with C# at all! Haven’t been since before .net core. I do ruby and devops. That being said, I have a side project with dozens of real users, closing in on double digit “market” share. I’ve needed to do some serious performance optimizations (it is a fork). The ValueType flexibility makes it easier to do these improvements.

Init applies to properties, readonly to fields (and methods in structs, or valuetype parameters).

The switch expression is something I’m also not sure about yet, but makes for less clutter in the editor. I think it’s part of a general strategy of providing the language with more compact syntax options. It reminds me of the pattern matching in F#. Did the language need those? Not really, but my biggest annoyance with older C# was the verbose syntax, and it factored into my perception at the time that it was a dinosaur language.

Roslyn is open source, cross-platform, written in C#, and can be forked. The analyzers can be linked as dependencies to any source project. I don’t understand the VS/Windows connection. They are just basically hooked methods that run during compilation steps and can emit compiler warnings, errors, suggestions, or automatically fix code. I think you are shooting yourself in the foot if you throw that feature out on pride.

Nullable reference types are optional on the file or project level and function more as type assertions, and don’t represent separate classes. I understand the frustration with it though. I think the language needed this in order to be able to statically analyze the expressions for nullability instead of relying on runtime checks. Those runtime checks are notoriously unreliable as a safety net because you have to remember to use it, and make a decision on using it. They made a tough call but I think it was the right one.

Structs are not records and are in fact mutable by default! It can be converted to a ref and then mutated, without unsafe code. The readonly modifier prevents that. I haven’t studied the nuances of readonly structs vs record structs yet. It’s considered a bad practice to use mutable structs (and undermines compiler optimization) but if you’ve ever had to refactor a class to a struct, with hundreds of usages, having the mutability can make the task much easier to do incrementally.

I think they are careful, but the decisions are very difficult and sometimes it’s a loss in either direction. C# prefers to change with the times but remain backwards-compatible, but I don’t envy the jobs of the language committee.