Collections Just Changed in C# 12 and That’s Good
ฝัง
- เผยแพร่เมื่อ 4 ต.ค. 2024
- Check out my courses: dometrain.com
Become a Patreon and get source code access: / nickchapsas
Hello everybody, I'm Nick, and in this video, I will show a new feature coming in C# 12 called Collection Literals. Collection literals aim to simplify how we are working with collections such as Lists, Spans, Dictionaries and Immutable types in C#, but it kinda looks like we are copying Python.
Proposal: github.com/dot...
Workshops: bit.ly/nickwor...
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: bit.ly/ChapsasG...
Follow me on Twitter: bit.ly/ChapsasT...
Connect on LinkedIn: bit.ly/ChapsasL...
Keep coding merch: keepcoding.shop
#csharp #dotnet
The code with the span does not use a stackalloc. It is an array as span. SharpLab can show you
You're right, I totally missed that! Pinning this so people can see it.
Maybe the should add a Span s = stackalloc [1, 2, 3]; feature?
@@Khitiara_ The idea behind Collection Literals is to simplify it and make it consistent.
@@Krimog true, and Im hoping they add stackalloc support to those - its been a topic in the proposal documents for a while now
@@Krimog the current state of the proposal seems to be that the compiler may switch to stackalloc later for performance and the design wont preclude that but i guess it isnt implemented yet
I've been a C# programmer for more than 20 years but cannot keep up without your insights. I'm retired now but still love programming. Thank you Nick for keeping me up to date.
Ooh! The collection spreading is one of my favourite aspects of JS. It's just so easy and intuitive to work with. Love to see it in C# too!
JS spread operator is also a common performance bottleneck, so use responsibly :)
Indeed, I'm interested to dig deeper into this and see if it follows array semantics instead of iterator semantics like JS does - which far too commonly and easily hides performance issues.
Now if C# could somehow implement JS-style destructuring operators and get really dynamic with object properties...lol, I'd love to see "Dynamic C#".
Hopefully, we can clean things up some more and create an object with {} and use .. to copy things to it. This application will be very useful when working with JSON.
Nice improvement. I would rather use curly braces { key: value, ... } for the dictionary syntax as that mirrors what is used in pattern matching as well as other languages.
I think there can be language parser issues with this approach, and that's why they are trying to find something else
This would also resemble the JSON syntax, which I think is the basis for most languages, that do it the same way.
I do love the feature, but I'm wondering why they couldn't maintain the same syntax they do as the array? For instance why couldn't we just have List nums = { 1, 2, 3 }; The compiler knows it's a collection by the type definition.
In case the team ever wants to do block expressions, List nums = { 1 }; could be ambiguous.
I would just use {} instead of [], as they are already implemented and just drop the need for the new keyword on lists and such. For the span, the type could also be implicitly derived, but I'd keep the stackalloc
Yeah, and I don’t like using the same symbol for array and dictionaries. Why not just keep the {} and infer the type/new/alloc part
This is the last remaining Python convenience that I miss in C# (the other big one being a better array syntax, which was implemented some time ago and used in this video). I am so impressed with the C# team in recent years. I haven't even considered moving to Kotlin or another language.
I hope it will be possible to initialize immutable types in the same way, even if there's a tiny bit of magic under the hood.
I really hope this makes it into official version.
6:14 _"To be honest, if you work with a span, you probably know what a stackalloc is"_
This is the kind of bold assumption that will ruin your weekend with a butterfly effect breaking change on a friday afternoon in an otherwise unrelated part of the solution.
xD Yeah, a couple of years later nobody will infer that in mind :D
I almost cried of joy when I saw the intro
Not sure why we need more and more syntax options to do the same things we've already been doing without issue. Sure this is convenient and I'll probably use it but is it really necessary? There was no better use of time for the C# team? Great video as always Nick
The only thing that gets me angry is the fact that the guy's working on C# knows all the easy/elegant way to write codes, and they've seen it on other languages, but they just beat around the bush for years, then come back and say "well, we just gotta do it".
Meanwhile, they've already created more ways to do one thing.
One day, they'll deprecate List mylist = new(){1,2,3}. Then later bring it back as a different function.
Honestly, this will be such a huge help in making C# code more readable.
Its a great feature.
This is really great! C# already has a decent syntax for collection initializers. (Except for Dictionary instead of Map). C# has roots in Java. (Remember the ArrayList thing?) It has improved its syntax a lot. And if this gets through, this would be another great improvement. Also, this simple syntax is used by many other languages, including JS, Haskell, Groovy, F#.
Although the ranges look a bit weird, I really like the seamless "listify" of a variable!
int [] i = [1,2,3,4];
int [] j = [5,6,7,8];
int a = 123;
List k = [ ..i[1..2], a, ..j[3..] ];
var str = "hello";
UseList([str]);
void UseList(List values)
{
}
FINALLY!! Even F# has it's own literals for different collections.
I would've preferred if the syntax used {}'s instead of []'s for consistency with the other collection initialisers.
I think I'd also prefer the special 'Dictionary' syntax to use '=' instead, so it's consistent with both anonymous class objects, and object initialisers.
EDIT: Or if you want to use : for dictionaries, then allow me to do var = raw JSON Object and get a dictionary set up that way.
Sure an array is an array. That syntax is established. A collection is a sequence and the sure we can adopt the [1, 2, 3] syntax for that . A dictionary would be its own thing. I would like the Dictionary to use curly braces: { "key": 42 } as it mirrors anonymous objects and object pattern syntax. Which I also would add support for: object-like pattern syntax on dictionaries.
As a typescript/C# dev i really appreciate these changes.
I love it and I hope the proposed one for the dictionary is maintained. Thanks!
seeing how c# evolved, and seeing what you can do with typescript types, and how rust manages heap memory,
makes me wanna write my own language taking inspartions from all of them.
Looks a bit like F# syntax for collection initializers but simplified. In F# it'd be [1; 2; 3] for a list, [|1; 2; 3|] for an array and [(1, "a"); (2, "b"); (3, "c")] for dictionary. Tbh I dunno which one I prefer. Same syntax for all collection types is easier to remember (I'm always stuck for a second when initializing list in F# - it begins with '[' or '[|'...) and there's no problem when applying it to custom collections. The obvious pro for a distinctive syntax is it could be used with 'var' keyword because the syntax itself gives us full info about collection type.
It would be nice to have a more consistent approach to this, why not use curly brackets for this? It is already used to initialise data for collections. This would make it imo easier to understand and easier to use. Square brackets for accessing data, curly brackets for initializing data. Keep it consistent.
I guess an argument dor square brackets would be that they are also used in string slices (or whatever they are called), and they have a similar syntax to the appendeding initialisation of collections..
This is discussed (extensively) on the proposal comments section. TL;DR a lot of people thought of curly braces, but it's not happening. For specific reasons.
I wish there were channels like yours for other languages like Rust.
There are so many videos about "the basics" but not enough about more advanced or new concepts and how to actually use them in a real project.
Finally!
Learned programming with Python, worked with c# for 10 years. so happy to see this.
Using [ ] as syntax is what they should have done in the first place.
Or Rust,
let array = [1, 2, 3];
let mut vec = vec![1, 2, 3];
let mut tree : BTreeSet = [1, 2, 3].into_iter().collect();
And this works with user defined collections.
As long as it does not cause any kind of confusion(like what happens with how heavily c# began to override '?' doing multiple different tasks), i think there's no such thing as 'bad' feature. And apart from what you said with the Span, i see no confusion here. I think one who never heard of this feature or even have limited c# knowledge looks at the code knows by default what it does and what will happen does not get confused by it.
This is awesome, I'm super happy to see it coming in the future. I'm surprised they went with square [...] instead of curly {...} brackets, I'd have assumed they'd keep the overall "physiology" of list and dictionary generation follow each other such that it stays intuitive even for a newcomer. I can only imagine it might be a parsing issue or perhaps to clearly indicate it isn't a constructor method but a shorthand.
I'd actually say C# is taking features from JavaScript, or probably in this case TypeScript because Anders Hejlsberg is responsible for both. As for other things I'd prefer them to use curly braces for Dictionary declarations - { key: value } - like they do in JS. And to instantiate immutable collections it would be nice if you could just do ImmutableArray = [ 1, 2, 3 ]; without any method calls.
I'd rather if they keep it as List list = { 1, 2, 3 } rather than List list = [ 1, 2, 3 ]. I'm so used to using { } for initializing throughout the past decade that using [ ] feels really weird to me. For most cases, it's as simple as just removing the new keyword, so why not just do that?
They shouldn't bother with arrays and List. Dictionaries could borrow the Python approach however: var dict = new Dictionary { 1 : "a", 2 : "b"}. Honestly, this is all I would do. C# can borrow ideas from other languages but not at the expense of getting overly weird.
More concise code is always welcome however current approach is ok in variable initialization. Variable declaration line being 10-15 character shorter is lesser deal than in more "buried" places. What I'm more interested is how clever compiler will be when it comes to more "buried" parts linq chains, short lambdas or inline created method parameters, especially when IEnumerable is expected. These places would benefit the most from the shorter code. Especially when you just want to have "temporary" IEnumerable made from very few elements or just wrapping a single one. I hope constructs like Enumerable.SelectMany(x => [x, DoWithX(x)]) or foreach(var x in [1,2,3]) will be implemented because right now it requires casting which basically is reshuffling of current initialization.
I couldn't stop laughing for joy. It might be a small thing, but damn, it will be a nice feature to finally be added.
This is unironically the best feature they could have made. This is one of the things I love about Python, and the fact that it's coming to the C# world? Huge win!
I would just think of all of these as an implicit conversion from array.
You can easily understand converting array to list and back, so converting them on compile time (or even earlier) still feels fine for me.
I would even go as far as saying that a dictionary is also easy to convert from a list (or array) of key-value pairs, so the language can also have it as implicit conversion.
As long as there's exactly one way to understand a syntax, and it doesn't hide anything important (such as runtime loops, scope, heap/stack etc), I think it's good for the language to understand (unless it bloats the language, which is not the case here)
looks fancy, good approach. For me all I need is a shortcut to initialize array property with an empty collection.
Like int[] ArrayProperty { get; set; } = []; instead onf in[] ArrayProperty { get; set; } = Array.Empty();
But this may cause a confusion between empty array reference and new array initialization.
I'd special case empty immutable (not-addable) collections and intern them
These types of things or syntactical sugars add up pretty quick in terms of productivity. Whenever I'm in python I wish C# had some of these features. With javascript, the spread operator (with objects) is another one which I have no clue how that could even work in C# but I can wish.
Yes this is good. Usually syntax sugers are kind of "meh" for me. But this is very good. It is a pain sometimes when initializing arrays and array abstractions such as list, dictionary etc. Also I like that C# is moving away from that old OOP stuff and is also incorporating concepts from other styles. I just hope C# will not become all in functional instead of OOP or what ever, but ever more flexible.
Also have you got any videos that shows examples of configuring the GC? If I understand correctly, you can actually replace GC with other GC and there are many settings too
Why didnt they just use {} for everything not just arrays
This looks amazing, and even better if/when they eventually introduce the "default" inferred collection type (when you assign an unspecified collection into var).
I would be perfectly happy if they started obsoleting some of the older forms of syntax with the option to turn them back on using compiler switches.
Yeah, too many ways to do the exact same thing.
Atm I feel like getting diabetes from all the syntactic sugar in C#.
Just program in C bro
i love that c# is like, lets steal all the good stuff
I wish the next "big" thing for C# would be union types someday. When switching from typescript back and forth I really miss this feature in C#.
OneOf for unions, inheritance w/ClosedTypeHierarchyDiagnosticSuppressor for discriminated unions. Don't mind me just puking in the corner
There is at least one proposal for type unions so I imagine it will happen one day relatively soon
@@smallfox8623 The soon for DUs has easily been passed by now imo
I would love union types. So, you don't always have to create multiple fields where only one of them is used afterwards
It looks like JavaScript or TypeScript and I absolutely love it
So they removed the need for new() (not necessarily good because it made even you believe that the Span was using stackalloc when it wasn't) and just added syntax from another language which is inconsistent with c# syntax...
Since arrays already have this feature, uniform initialization between collections wouldn't be bad but using [ ] instead of { } seems utterly unnecessary, as does the syntax for dictionaries.
I don't mind pulling features from other languages. As long as C# doesn't make white space characters as Python!
This feature could be done more in C# syntax, instead of [] to use {}:
List array = {1, 2, 4, 5};
Just like it is done in C++
As also a TS dev, I appreciate this feature.
there's also this confusing syntax which uses {} and looks like an assignment, but is actually calling Add under the hood. So maybe using [] is more appropriate to indicate you're initialising a collection, and not adding to one.
var n = new Numbers
{
List = { 4, 5, 6 }
};
Console.WriteLine(string.Join(",", n.List));
public class Numbers
{
public List List { get; } = new() { 1, 2, 3 };
}
The new syntax also calls Add under the hood for every element. These two lines are exactly equivalent in IL and both call Add for each of the three elements.
List list1 = [10, 12, 20];
List list1 = new() {10, 12, 20};
@@smallfox8623 ok, fair enough. ignore me so :)
In F# this already implemented. Square brackets for lists, square with | for arrays.
yet no literal for the dictionary/map
Simplicity is great for readability so long as it doesn't come at the cost of something else. like you might loose specificity. Luckily these collections are still labeled both by name and type so this simplification seems only a good thing.
Im very glad of these changes, it's much more readable, it looks more like typescript
It is not a paint in the ace to concatenate an array in fact because of the LINQ queries and AddRange() method in List < > which is even more readable.
I did not know that the List does have a Dump method.
It doesn’t. It’s a sharplab thing
I was about to say the same thing, but with Nick's reply, I think "Dammit!" is more appropriate. 😛
Shame there is no proposal for this feature. Or is there????
In the interest of showing distinction with the arrays, using curly braces for modifiable collections (those with add, remove methods as example) and using sq brackets for arrays and similar objects would be more appropriate and consistent.
I see your point but disagree, as it would diverge from list pattern matching syntax
The syntax doesn't look nice nor fits with other C# code. The dictionay should always be with curlies imo (though they probably opted for the brancket because of some compiler limitation). And most of the overhead is still there having to specify the type of the variable.
Finally a real comment without the wow. The syntax looks ugly and unreadable.
@@alexandergoncharov9610 I think you meant "Finally a comment with the same opinion as me". C# is my favorite language but I regularly work with JavaScript and Python and I have long been annoyed by the unnecessarily verbose syntax for list initializers in C#. That you find it less readable does not mean that most developers will. Even though I agree with some of the criticisms, I think it's a great improvement and you'll get used to it too.
@@dhochee I don't believe it when the crowd screams wow. By the way, Nick has a video,
for which great respect, where he shows one very wow way DI (dependency injection) for c# net core, which the minority immediately criticized for unclear behavoir.
The same var keyword, is a very harmful thing.
But of course this is only my wrong opinion.
Have a nice day :)
This looks really good but I was wondering what will happen if we do var x = [1,2,3,4] . Will it take it as a list or a array or do we get a compilation error?
creating a list was never a big deal for me. the feature is cool, but let's be honest, it's just modern syntax sugar and will make code styles even less consistent
Yeah totally agree with you, its only hard for non c# devs. c# used fo have a consistent syntax now c# is becoming javascript 😂
@@onyxgc2568 and that's concerning. that small productivity boost might not be worth having to learn extra syntax.
Love the Python-like syntax. But it's gonna add to the problem of having multiple ways of doing the same thing like timers for example. They should release a version which gets rid of all the old stuff at some point.
Rather they remove the new stuff tbh. But they wont remove old stuff for backwards compatibility which im 1000%on board with
@@frederikja2210 what? why remove the new stuff? Remove the old. If you release a new version of something that's your chance.
A lot of existing code base would break and it would require a lot of work for a lot of developers to fix their code, which means a lot of time and money. They will never remove existing features from C#.
@@LudwigvanBeethoven2 hence why I'm talking about releasing a new version. Python did it perfectly. Switching from version 2 to 3, everybody said the exact same thing as you first. Now everything Python is running on Python 3. So please...
I think this is great, but the square brackets for dictionaries feels odd because many popular languages use curly brackets
wym? 've been using square brackets in dictionary initializers for a long time now. Because `{ [Foo] = Bar }` reads better than { { Foo, Bar } } in longer lists imo
@@dennycrane2938 What you’re saying has nothing to do with what I’m saying. Those square brackets surround the key, not the whole dictionary. (Also, `{["key"]: "value"}` is valid JavaScript)
I believe c# is obsolete. But not the expressiveness of the language itself. Take a look on async-await. If in a chain of function calling (the fancy name with the graph does not pop into my mind right now) you have an async, then it is advised to change all other functions to async. As a backend dev, I either save something (async) or I am calling a webservice (async). So, I need to write thousand times a day: async-await. Does not make sense, especially because this can be automatically decided on the fly. I would love to see a c# where I can configure how my code behaves, and choose auto async-await functionality, or different memory handling ,etc. And leave the language distilled, with a theoretically solid background. How do you find design patterns regarding to new features in c#? Do you write them differently now? The language turns into more procedural/functional. Should we reconsider using anemic models? what will be the desired style? Following guts feelings and forget the theory c# was built on? These feature-stealing looks cool, but I feel c# looses its solid ground. If someone wants to code python-style, do it in python. same with go. But, doing python or go in c# ....There are so many other ways to enhance c#, I feel a bit of wasting time to force it into this direction. What do you think?
This looks really interesting and I for one am looking forward to using it
I am so happy that I've chosen c# as my first programming language to learn , it's so powerful and great features and amazing support from Microsoft and great future
I like it. Very similar to JS, at least in syntax. Love the spread-style operator, too.
C: I am basically every programming language because of my macros
C#: I'm literally every programming language.
This is beautiful. They have to make these features in the final version.
i love it, i had exacly same problem with having both {} and [] doing the same for array, but i get why they used [], because of those operators ".." (not sure if there are more operators available for [])
Omg finally c# designers add useful simple way to creating collection objects.
It’s looking similar to how Swift initialises dictionaries and arrays.
Nice feature, thanks for sharing Nick!
Great Video Nick, a question is allocations especially the syntax that looks like a spread in javascript. Would this be performant?
I looked at the IL and each "spread" compiles down to an iteration with the list's Enumerator along with an Add call for every element (exactly the same as foreach). So this
List combined = [..list1, 7777, ..list2];
Is equivalent to
List combined = new List();
foreach (var i in list1) {
combined.Add(i);
}
combined.Add(7777);
foreach (var i in list2) {
combined.Add(i);
}
I don't hate it... the only thing that bothers me is that it hides the new... I like to be able to search for "new " to know where my code is allocating new objects - for re-factoring purposes... but as I said I don't hate it since I can just use the old syntax...
My immediate question; is the new syntax converted at compile-time to the equivalent old syntax? Or does it initialize an intermediary collection and thus have a performance hit (however small)
var i = new int[] { 1, 2, 3, 4 };
int[] j = [1,2,3,4];
in the current version, i and j point to the same memory location. So initialization is exactly the same.
That is very typescript and I love it… types and type combinations should be the next thing
Love this feature a lot!
I'm curious why they went with square brackets instead of pulling from C++ with its curly brackets which are used in the exact same way (just like the array syntax). I wonder if there was some sort of ambiguity with some other feature i can't think of?
Love it, just like javascript/typescript. I wish the spread was three dots not two.
1:55, do the 3 lines are mandatory?! In C++:
std::list listOfNumbers { 1, 2, 3 };
std::span spanOfNumbers { 1, 2, 3 };
std::map dictionary { { 1, "one" }, { 2, "two" } };
Basically, I see typescript. But I love it! ❤
It feels like C# has been slowly turning into a hybrid language. It's becoming more and more a language that better supports a functional style. I like this feature (with those similar caveats) and most others but it feels like the language has too many features.
I prefer to have options than limitations
@@bluecup25
I can absolutely get behind that thought. The only thing I feel is an issue is how it can be dizzying how many options there are. Almost like teams have to decide what options they don't want to use for consistency reasons.
@@logank.70 True. Also I like the fast progress of C# but I hope they put plenty of thought into new features and don't create problems impossible to solve in the future (or with ugly workarounds to maintain backwards compatibility).
I was waiting for this a long time 👏
Wow! I really like these changes coming to CSharp! I think those are good features overall and don't really dilute CSharp at all.
From the thumbnail I thought they included list comprehension lol but we can only hope
Add list comprehensions and we are cooking.
Seems like the curly brackets shorthand for arrays was not forward thinking enough and is one of its kind.
How it sneaked into the language like that, considering there are other features delayed forever until they decide on universal solutions...
So, I'd deprecate that one and always use the new universal syntax.
My argument pro square brackets syntax:
It makes collections initialization distinct from all other code blocks.
Wrapping curly braced objects into parentheses due to ambiguity is kinda annoying.
If this allows to avoid that inconvenience when returning an anonymous collection instance, then it is a wise choice.
I love this personally, so much easier to work with!
Would have liked if they had a different syntax for arrays, lists and spans(square brackets for one, curly braces for the other, and then even something else), so you could still use it with the var keyword. If you use the var keyword with this new feature, C# probably doesn't know if you want a list, an array or a span.
Also wished the 2 dots were 3 dots, so it becomes the same syntax as javascript's destructuring
The [ 1 : "One ] syntax is unique to Dictionary, so the compiler should be capable of determining var as Dictionary.
Not sure if it's planned, but it should be possible.
I was thinking this the other day, using top-level statements only.
I love how C# is adding more and more functional syntactical sugar
I like this. I think more languages should give better options to initialize collections. I'm not a C# programmer outside of some small uses, I mainly deal with javascript/typescript (I know, horrible etc), but the approach there of just typing in a fancy json object is amazing for manipulating collections. I hope this will work the same for non-assignment operations as well (ie. an inline return from a function. Compiler knows the type, since it has to match the function return, so it might work)
I guess the implicit stackalloc might not be great, I'd leave the keyword in front of the array, just for clarity. Without having to do funky syntax or the full types it's still a lot better, even if that gets left in.
Really wish it would be smart enough to understand something like List strings = [1, 2, 3].Select(i => i.ToString()).ToList();
I can't see any funny channel about Java like your channel
I don’t really like the change, but I can see how this improves typing speed. I don’t find the new form simpler to read or the old one harder. It’s just shorter.
Noce video. Nick,when are you going to try and make a video about the new GPT code interpreter? It's very powerful
I find the current way just fine as it is.
But I use var to not need to specify the type twice, along with other reasons to use var.
It doesn't work with var as there is no type declaration. I won't be able to utilize this feature, but I'm not bothered either.
For the ppl that like it strong typed instead of var, I can see why you'd want this feature to write less at the right hand side. The left hand side is already clear enough what the type should be and the right hand side will be easily constructed this way.
I love this feature. Square brackets for me are just fine. Spread operators FTW!
wake me when they get to comprehensions, they are the killer feature of python syntax.
Another feature that I would like to see is multiple return types (like Go does). Instead of declaring a tuple explicitly to make it more native-like.
I really hope the main idea behind these new features is to simplify interop with F#. Passing collections between F# and C# packages is a bit of a pain in the ass rn
Not too bad - at least it's easy to read.
I find this obsession adding more and more syntax in order to create less and less code gets a little over done at times and we end up with very difficult syntax to read with way too many ways to perform the same task, but in this case it seems fine and just simplifies.
An example of what I didn't like was raw string literals in 11. Even the example on the MS docs makes my eyes bleed:
var location = $$"""
You are at {{{Longitude}}, {{Latitude}}}
""";