Collections Just Changed in C# 12 and That’s Good
Vložit
- čas přidán 12. 07. 2023
- 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/dotnet/csharplang/...
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: bit.ly/ChapsasGitHub
Follow me on Twitter: bit.ly/ChapsasTwitter
Connect on LinkedIn: bit.ly/ChapsasLinkedIn
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.
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 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
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 really hope this makes it into official version.
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
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 almost cried of joy when I saw the intro
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#.
Honestly, this will be such a huge help in making C# code more readable.
Its a great feature.
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 love it and I hope the proposed one for the dictionary is maintained. Thanks!
As a typescript/C# dev i really appreciate these changes.
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.
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)
{
}
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.
Using [ ] as syntax is what they should have done in the first place.
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.
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.
Nice feature, thanks for sharing Nick!
FINALLY!! Even F# has it's own literals for different collections.
This looks really interesting and I for one am looking forward to using it
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.
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 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)
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.
I was waiting for this a long time 👏
I like it. Very similar to JS, at least in syntax. Love the spread-style operator, too.
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
Finally!
Learned programming with Python, worked with c# for 10 years. so happy to see this.
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.
Love this feature a lot!
Noce video. Nick,when are you going to try and make a video about the new GPT code interpreter? It's very powerful
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.
As also a TS dev, I appreciate this feature.
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.
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?
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 [])
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.
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.
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.
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.
Cool presentation Nick. I like this new feature and it looks very clean and readable. Except the dictionary one. I'm not sure if this is a good way to go
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.
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
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?
Very nice!
Wow! I really like these changes coming to CSharp! I think those are good features overall and don't really dilute CSharp at all.
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);
}
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!
Finally. Very nice !!
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.
Looks nice! However when using other collections in initialization of others, the double dot prefixes seem redundant, don’t you think?
Also it’s weird that array can be initialized with both square and squiggly brackets. Wouldn’t it be cleaner if they kept only the squiggly brackets and used them for initializing other collection types, instead of squares?
I love this personally, so much easier to work with!
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++
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 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 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?
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
Im very glad of these changes, it's much more readable, it looks more like typescript
That is very typescript and I love it… types and type combinations should be the next thing
I liked a lot how to concat lists, it is just beautiful
It looks like JavaScript or TypeScript and I absolutely love it
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.
I don't mind pulling features from other languages. As long as C# doesn't make white space characters as Python!
Love it, just like javascript/typescript. I wish the spread was three dots not two.
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 :)
That looks fantastic!
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.
In F# this already implemented. Square brackets for lists, square with | for arrays.
yet no literal for the dictionary/map
Will we get ranges/indices for List?
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 love that c# is like, lets steal all the good stuff
Just love the new syntax. Easier and cleaner which is the point
Why didnt they just use {} for everything not just arrays
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
I love this feature. Square brackets for me are just fine. Spread operators FTW!
C: I am basically every programming language because of my macros
C#: I'm literally every programming language.
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" } };
I would have preferred the curly brackets {syntax} from arrays instead of [ ].
05:20 Curious how that is implemented below the surface. It can be done in a way that wastes memory or not.
Current implementation initializes the list without a predetermined size, and it adds each value one per one to the list.
So yes, not very optimal at the moment ...
Basically, I see typescript. But I love it! ❤
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.
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????
Is there a reason some dev refrain from using the var keyword (in cases where the type is already unambiguous)? It seems like the cleanest way IMO but I see a lot of devs writing the type explicitly and sometimes even with the constructor call.
From my anecdotal experience, it has been because they feel like writing the type brings more clarity and is safer. I don't agree and feel like that mindset brings a false sense of security. I like using var because it makes me name the variable in a way that better describes what it represents.
Feels like JS, awesome !
I can't see any funny channel about Java like your channel
Nice, collection initialization is a pain. Especially dictionaries. I like python style - no need to type many symbols and no need to read a lot of symbols after than
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.
Is it not a direct copying from the features of JS and ES6, except for 3-dots vs 2-dots?
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}}}
""";
From the thumbnail I thought they included list comprehension lol but we can only hope
Using two collections to initialize a new one is fine. But I doubt the utility of standalone initializers. Outside of demo foobar code, how many times do you encounter hard-coded collection initializers?
What is it with span and stackalloc?
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
It’s looking similar to how Swift initialises dictionaries and arrays.
amazing