I’m sure a lot of work went into this, but it seems crazy that we need another way to initialise collections, and another way to make fixed sized arrays.
This is for custom collections, right? And you don’t even have to use it, you can keep using existing ctors for your custom collections
Worse case scenario you keep doing what we’ve always had to do. But for the 99% of use cases we get a much more streamlined initializer, with extensions to use our own.
they actually have to reference the function by string name.
This is true of a lot of the opt-in language features though, isn’t it? For example, you can just make an and get collection initializer syntax supported for it, even as an extension method. The same works for Dispose on ref structs I believe, and I remember there being a few other places where this was true (GetAwaiter I think?).
I think for arrays it’s not really a benefit. But for other types it’s superior, compared to the current syntax which just calls add on the list object, which is very inefficient compared to building the whole thing at once which is what this new syntax does.
I do feel like C# saw C++ and said “let’s do that” in a way.
One of the biggest selling points about the language is the long-term and cross repo/product/company…etc consistency. Largely the language will be very recognizable regardless of where it’s written and by who it’s written due to well established conventions.
More and more ways to do the same thing but in slightly different ways is nice for the sake of choices but it’s also making the language less consistent and portable.
While at the same time important language features like discriminated unions are still missing. Things that other languages have started to build features for by default. C# is incredibly “clunky” in comparison to say Typescript solely from a type system perspective. The .Net ecosystem of course more than makes up for any of this difference, but it’s definitely not as enjoyable to work with the language itself.
I think one of the things holding back some of the more impactful features we could see in C# is the need to also update the CLR in many cases to handle things like new kinds of types, new kinds of expressions, etc. TypeScript has the benefit of being executed by a dynamic runtime, but C#'s runtime is unfortunately statically typed, meaning it also needs to be updated with the language. It’s also used by multiple languages, for what it’s worth.
That being said, if they redirected some of their efforts towards improving the CLR as well, I think they could put out all the cool features they’ve mostly sidelined, like DUs and some form of their extension everything proposal.
The great thing about languages like C# is that you really don’t need to “catch up”. It’s incredibly stable and what you know about C#8 (Really could get away with C# 6 or earlier) is more than enough to get you through the grand majority of personal and enterprise programming needs for the next 5-10 years.
New language versions are adding features, improving existing ones, and improving on the ergonomics. Not necessarily breaking or changing anything before it.
That’s one of the major selling points really, stability and longevity. Without sacrificing performance, features, or innovation.
Add comment