The First Feature of C# 13 Is Here!
Vložit
- čas přidán 1. 01. 2024
- Use code MICRO20 and get 20% off the brand new "Getting Started with Microservices Architecture" course on Dometrain: dometrain.com/course/getting-...
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video, I will introduce you to the first brand new C# 13 feature called, params collections.
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
And let's not forget that using params alongside with other parameters, you are forced to put them in the very last spot of the signature, whereas with the [] shorthand you have much more flexibility! (multiple params)
But indeed, a welcomed change.
I think it will look nice if you have a method with only params then you can pass them nicely delimited by a comma. But if you have a method with other parameters and params then it would look nice to use the [] shorthand and you can easily see that there are different things and an array.
Upgrading params to modern C# is welcomed.
But I doubt the need is real now we have the collection syntax.
It feels like low hanging fruit, the implementation borrows probably from the work done for collection syntax.
I wanted the ability to do this with params IEnumerable back around the time when C# 6 was released. I can't believe it's taken this long.
"Param Pam Pam" lol
Could you please do an explanation/deep dive of the performance impact of the old school 'params'?
Also, I think that 'params' parameters being optional is an important part of its use case. It may be desirable to allow passing a set of parameters to a method while having reasonable defaults if they are omitted. Think of the 'args' parameter of every 'Main' you've ever seen
I use the "params" keyword quite a bit. I'd estimate that 90% of the time I use Linq on the array, and 9% of the time I use a foreach. I may switch to an "IEnumerable", but the simplicity of "T[]" may be hard to give up.
I knew immediately what the new feature was when you mentioned params. The limitation to arrays for this keyword is the number one reason for the ToArray() call in my code base.
Imho people should try to define their types passed in, not using stuff, for just "I don't know how many parameters I'll have". Params used to represent exactly "I don't know how many params I'll have", because that is how you can write for example functions that has template parameters etc.
Most of the time where I hit an issue with params isn't so much the type being defined in the method, it is what I am passing to it. Sometimes I inline values. Sometimes I have a collection to pass. If I am understanding this feature correctly I could just target an IEnumerable now in the method, and I'd be able to inline values, pass an array, a list, an enumerable, or anything that supports IEnumerable. If so, that is great. Will make tests easier, as that is mostly where I use params these days.
It seems to be a feature which is intended to optimize some edge case scenarios. For example logging methods usually have params so it can probably speed up the method call of such a function.
As we already have the params keywoard and can't remove it for backwards compatibility i think making it more modern is better than nothing. Yes collection Syntax is a very similar and in many situations a better approach but in the cases where a params parameter looks more readable (for example single array argument methods) it should support modern types.
I think it is an okay* feature in terms, but I would prefer a more "open-ended" approach like we have with GetEnumerable or Deconstruct. I mean, by making it as a function of a type so user defined types can also receive the use of this (and of course, in the CLR types you can squeeze them more by making the most optimized version of it).
I think the just because the feature remove corner cases from the language it should be added even if it won't be widely used.
Making existing feature frictionless is really important for new developers.
I pretty much agree with Nick, that they should add it for consistency, and because we have the keyword anyway. But personally I wouldn't use params in my code, as it makes it opaque, that the arguments get packed into a collection before executing the function.
Interesting to see what a community can implement with params collections if we will be able to extend params to other collections and even custom types.
Cool! I doubt I will ever use this
Although the span bit looks useful (I really should get into the habit of using spans)
I've been following this feature for quite a while already and I do think this feature is very helpful with possibility of slowly optimizing the core framework itself as well.
If i recall it correctly, there was a discussion of providing a span overload for every external API that uses the params keyword.
This would allow the compiler to check if such an overload is provided and possibly prefer the span over the Memory allocated, based on how the method is called.
Is it a small constant collection, then take the span or even optimze the collection allocation all together if possible. Is it a collection of an unknown size, then take the collection overload.
And since an upgrade of dotnet core is pretty straight forward for the most part, this change would go unnoticed until you look at the improved performance!
If I remember well, `params` was added to support declaring function signatures for interop, for marshalling parameters for functions defined in C/C++ as vararg/"...". Except for this usecase, IT NEVER had much sense, other than sometimes give us some break from explicitly creating explicitly typed parameter bags. From the moment years ago when we got the ability to write "new[]{ 1,2,3 }", 'params' lost most of its reason to exist, and maybe "declaring function signatures for interop" still holds it to some extent (but IIRC for some time already we have some new [attributes] that also help with vararg marshalling, so maybe 'params' have already lost all reason to exist). "occupying space" and "updating and reusing old feature just because we can" is NOT a good idea. If array-expression-at-the-callsite can cover all cases that params provide, then params should no longer exist. Having them both will only cause people to argue over apples over pears again
The sample provided is limited by using collections created just before call. But, it can be external parameter coming from above method as one of arguments.
If method can accept params collection as List or array from different another methods, then it`s much more comfortable to read than to require to convert all arguments to the only possible collection.
..something like:
void Method1(int number, string[] rows) => Method3(rows)
void Method2(string s, IReadOnlyList items) => Method3(items)
void Method3(params IEnumerable collection) => { }
I wouldn't mind a python like kwargs feature. maybe they should let us use an IDictionary too.
Woohoo, C-style stack varargs in C#! We're finally catching up!
As always thank you for sharing! At the middle of the video I just thought about exakt the same thing you mentioned at the end! And for that reason I will not use params!
It never gave me more readability and still does not! In fact writing single parameters as values of eg List confuses (me personally) more than it helps.
Why not, makes sense to also make it work this way in stead of having to explicitly convert an array to any other collection type for whatever reason.
Why is Memory not allowed?
I use params frequently, I know with this new collection initialiser becomes limited compared to larger compatibility of the latter but in many cases I just need an array, and passing parameters as simply as the params allow is great, the method declaration IMO can have the overhead of params since I will not be seeing it that much but when I call it its just LoopThis(1,2,3); again with the new [] declaration we can get more versatile so I wonder if is needed the params compatibility with other types? What excited me is the performance update and admittedly I never notice the performance drawback on the current version, you can indeed make a video on that if it is relevant still
An interesting feature. Nick gave a basic example but how (an example) would you use this in production code?
My main issue with params is that they need to go at the end making it impossible to introduce extra optional parameters, so beware if you use it in apis
Great video!
2:20 uhm actually that new array that you've selected there in the lowered code is just the unused var arr. The actual array is inline
For library authors that exposes methods accepting params it now allows them to squeeze more performance w/o forcing to update every usage of the lib.
release to release I'm waiting feature "Enum with generics" that allow us to use ADT and unlock new possibilities for pattern matching, code architecture and code design.
Only thing I want from params is stack allocation. You can always overload if you need other signatures.
I am curious, why does the lower-level C# code use a variable (num) as an indexer for assigning values to the span? Rather than just constants, like span[0] = ...
Both syntaxis are cool. The "params" is more readable and understandable, but it has to be put at the end of the list of signature parameters, that makes the bracket [] option is more flexible. Anyway, C# has a lot of syntactic sugars, so if Microsoft release this feature, we will have two options and the choice is up to developers. Better, then nothing
I might have missed something, but how it this readable at all? When you call the method it looks like you've giving specific parameters, but you're actually giving it a collection/array.
Aww, I was hoping IEnumerable could be used to lazy load parameters, sort of like shift in Perl!
Would it be possible and/or logical for Microsoft unify the new params keyword and collection expressions, by which I mean using either results in the same lowered code, assuming isn't already the case? In principle, this would mean types that define a collection builder could also be used with params.
The following code illustrates what I mean by this:
```
void Example1(IList list) {}
void Example2(params IList list) {}
// The following statements are all lowered to the same code:
Example1([1, 2, 3]);
Example2([1, 2, 3]);
Example2(1, 2, 3);
```
This feature is way overdue, and very welcome IMHO. I personally dislike the newer collection initialiser syntax because i don't think it's intuitive and, like most of the other recent language features, increases the learning curve for new devs. Params is more akin to the varargs concept in other languages. It results in cleaner calling code, and also lets the author of the method exercise greater control over how it's called. Hopefully it doesn't break existing collection overloads in legacy codebases.
I actually use the params keyword regularly and dont think its not used. For utility or very generic things it works like a charm.
What about tuples? Will it be possible to avoid writing methods with tuple parameters like this? "Example((1, 2, 3));"
@Nick Chapsas in which scenario we need params keyword. I never had dealt with it.
I like this feature. I occasionally use the `params` keyword. However, I prefer to avoid using this keyword, because it sometimes makes the use of overloads a bit tricky. It is useful for convenience, though, and makes method calls a bit like JavaScript functions.
It's not a new keyword, it makes sense, it does not contribute to bloating C# and it doesn't make anything slower. So there is not a single reason I can see why this should not be added.
I've always made params versions of methods just forward to one that takes an ICollection instead.
I'd still really like to be able to put stuff after the params to modify behaviour...
e.g. void MyFunction(params int[] coolArray, int extra1 = default, CancellationToken token = default)
callable as: MyFunction(token: cancellationToken, 1, 2, 3)
Since IEnumerable and IReadOnlyCollection work, am I correct in assuming that ISet and HashSet will work just fine?
I wonder if the ReadOnlySpan comes from an array or memory pool. 🤔
I would actually expect a generated stackalloc if possible. Then no heap alloc is needed.
But when you pass a string literal, and you have a ReadOnlySpan or Span of chars as parameter, then the string will just come directly out of the loaded compiled binary.
@@jongeduard Sure, but correct me if I'm wrong here, stackalloc only works with specific types.
@@urbanelemental3308 Yes, you are right with that, just unmanaged types indeed.
And that's where so called inline arrays come into the game, which are a new C# 12 feature that Nick has also talked about in his videos.
Which still use the stack though.
And I realize they actually already use that with the current collection expressions, I just verified it on Sharplab now, by combining a collection expression with a Span variable.
I used to use param keyword a lot when method declaration. It allows you some sort of overloading letting you invoke the method with single param or an array. So I'll really appreciate this new feature 😊
Have been using it for the same exact reason. Way nicer code when you use params instead of making two functions where one has a single parameter and the other a list.
@@KingOfBlades27 you got me bro 👍
Hands down, the only time I use params in my code is when I am doing extension-methods. I feel like there are other - better - ways to achieve the same idea. Although after this demonstration I kinda like it... So I'm conflicted
We just got C# 12 💀
Which is what you can have said about C# 11 and any earlier version as well. A new version is created every year, and released in november.
This is good, but they have improved the syntax tokens in VS Code and that's really awesome!
For me, I use params still today when to my method someone can pass one or many arguments. So, I don't have to create an overloading.
Can I still pass an array to a function that uses params? If not, then the func([1,2,3]) is better.
Either way, they could've just do away with the params keyword. Now they just have the same feature twice
10:43
Well, you can also argue that it have no benefits over other approaches so it should not be recommended for usage in the future in this sense, the old problem of "having multiple ways of doing the same thing" will start to rise more and more on these things.
Why is that a problem though? Java used to be (and still is to a big extent) very resistant to adding multiple ways of doing the same thing. That is why you had to make all these subclasses and instantiate new objects just to do basic operations (look at code before lambda functions were supported). With some functions you have to pass in a brand new array, just so it can get the type from that array, then throw that array away and use that type. It's kind of gross. God forbid they put something into the language to make it easier to use. It's all very verbose as hell just because Java doesn't want to add something that already technically exists. Hell you don't even have a parameter for the number of decimal places for rounding in the Math.round function (because technically you could just do the math yourself so why would they give you that convenience). This is what happens when a language doesn't give you multiple ways of doing something. That's one of the beautiful things about C# is that you do have multiple ways of accomplishing the same thing. This isn't a problem, it's a solution!
@@pharoah327
I think you are overthinking what I said. I'm not saying this on such an abstract level that some people take where if you can do X by A + B + C + D + E + F + G + H and by just doing Z it is "doing the same thing multiple ways", I'm on a more "sharp" edge here where I think even you can recognize that using params and just using the new collection literals will not "complicate" the life of developers in any way, and that in the end they are basically exchangeable one to the other. It's basically the difference of (x, y, z) and ([x, y, z]) and frankly, I find it's less confusing this way as well (and it have the advantage of allowing multiple arguments like these while params has only one).
yeah variadic functions are a real pain in C#, this looks great
The biggest benefit of params is that you do not HAVE to specify an argument, calling the method without a value in that spot is acceptable - this is why it MUST be the last 'parameter', the same reason that you have to specify a default value, every parameter after that MUST also be default.
I don't think this is a big issue - one way or another. Spans are nice, but they are just optimization, and if you need that, then explicitly use it.
I would prefer effort on something really useful like discriminated unions ;)
No link to the GH issue anywhere
It feels like C# is trying to do all those neat and high performing things C-language has with pointers and stuff, but it wraps them into all these syntactic facades (not the word I'm looking for but can't come with anything better right now). Nothing wrong with that but it's a bit funny for an old C programmer like me.
I would like a variant of params that enforces at least one parameter
There is no link..
I don't know. It is syntatic sugar. But to be fair, everything is syntatic sugar for something more metal. I say it can't hurt. I have only ever used the params keyword a couple times, just pass int the datastructure.
Have been using params here and there. Only annoying thing about it is that it only takes arrays so this is a great change 💪
I'm at 2:18 and I have to say I absolutely hate "params". If you see a method saying DoStuff(1,2,3), how would you know the method doesn't have three parameters?
I knew that spans had something to do with this
Would it also work with a dictionary?
I like the idea, but I think my issue would be to remember to use it
I would rather make the keyword params obsolete. This proposal just increases the language complexity. Now with collection expressions, the difference is just two characters and the benefit is that it is obvious that the collection is being created at the callsite.
Completely agree. params is so implicite.
having two or many ways for same thing is called polymorphism 😂. C# becoming so funny. now teams going to have much debates over syntax and standardizations for the company or projects
Frikkin' finally!
Why do you think most people are not using arrays? If you have a collection you don’t plan to add or remove items to, as you should be doing with function arguments, arrays are a fine choice.
Because you have so many alternatives like IReadOnlyList, ImmutableList or even the IEnumerable interface. If your collection already was a List and you wanted to pass it to a function that accepts an IReadOnlyList you wouldn't need to cast it or convert it to anything else. On the other hand, if the method accepted an Array, you would have to implicitly convert it to an Array.
Fun fact, Array implements IReadOnlyList so you can have an argument of IReadOnlyList and pass an Array to it.
@@pretzel7gmind blown 🤯
Or just pass through a Span.
I just use list every time unless there is a specific reason to use an array. It's consistent, and I find lists easier to use.
@@pretzel7glists do not exist in memory, it’s the same array with some metadata and other methods
isnt it weird that the compiler generated a 'num' variable instead of using literal numbers for a fixed-size arguments call?
No one uses params? News to me. I really like these changes, though one thing I wish they would do is automatically use stackalloc with the params array if it can figure out that the array reference is not shared outside the method.
Param pam pam.
2:42 We have spans
It would be nice to have named params after params keyword
Maybe then we need to drop the keyword PARAMS ?
Semantically they are completely different things, even if functionally are quite similar.
C# 13 and here we go ... another features trots...
I think this is "completing" the params feature, piggy-backing off of collection expressions. Personally I don't think I'll use it - I think simply wrapping the arguments with `[]` is better, as it allows you to use arbitrary orderings (as `params` has to be last).
If `params` didn't already exist, then this proposal shouldn't be added, but given that it already exists then it definitely shouldn't be needlessly stuck in the past (Looks at you, Expressions...)
Another thing to consider is the fact they could now add span-based overloads that could "magically" improve performance of pre-existing code, which is nice.
Beautiful idea😘
I prefer the updated params over collection expression/literal syntax on the call site. Those two extra squared brackets on the call site with collection/literals are UGLY compared to the elegant method call that params let you write.
@nick it would be better if you start a subscription plan like udemy business.
I wish seeing `params` less often (due its limitations), is it me living in bubble or Nick? 😜 Nevertheless, this seems to be meaningful language addition.
Sum types when?
After they release new C# 12 feature with collection literals I dont think that "params" feature still relevant. So I think they should leave params as it is and focus on more important things
avoid params if you have something like this:
public static string GetLocalizedText(string groupPath, string itemName, params object[] args)
public static string GetLocalizedText(string groupPath, string itemName, string defaultText)
I like the new feature, and it does not add a duplicate syntax like the (still wonderful) new array declaration syntaxes.
I do not like a string parameter supporting a set of input chars. It seems unintuitive and "clever." This isn't C. We have ReadOnlySpan, which was the original intent of this new feature.
Yooo
It's a nice feature, but I wish they would focus on things like Discriminated Unions instead. The C# community could benefit more from such a feature.
For building CLI tools, it makes some sense.
But for changing method invokation... Clean Code recommendation is to avoid passing more than 4 arguments. If passing more than 4 values, then we can have some line of code building the array. It's perfectly OK. So, I'm not against this, but I'm not thrilled either.
Blah blah Clean Code… every thing needs context learn to be pragmatic instead of following book dogmas.
How fast is this language evolving? A little bit to fast for my taste. But don't understand me wrong. I love nearly every new feature. But currently I don't have the time, beside my study, to learn all this new features at work.
The answer is too fast, imo. I've had the good fortune of being able to work solely on my own project for the past two years or so. The first year I slated a lot of time to catch up on all the stuff I had fallen behind on in the prior few versions of C# and .NET, and that was A LOT. The language was already virtually unrecognizable. There were already so many new features (say .NET 6 through 12) that none of the devs were using out in real life scenarios in the workplace, not because they're not good, but because the devs were too busy actually trying to build useful things to set aside the massive amount of time it takes to stay on top of the new syntaxes, libraries, and best practices. You can spend 40 hours a week just trying to stay on top of the new stuff, and I'm not even joking. While its cool to learn and know these things, you're going to get pushback if you ever try to use some of these bleeding-edge things in production code in an established team environment. It's too much, imo. As developers we're supposed to be aware of all the language features, syntaxes, notations, and libraries in case we run into them, but they're making that impossible with pushing out too much stuff too quickly. We can't architect, build, implement, and debug all while staying on top of all the new stuff being churned out at the same time. It's a conundrum.
The problem with params is that either empty params should be a valid thing or there should be an overload which signature forces to provide at least one argument: `Example(int value, params int[] other)`
I think if you send it nothing, it does result in an empty array (or collection). It is then up to the function to check if it's null or empty if that needs to be a special case.
@@pharoah327 exactly, and if empty collection is not a correct input, then method signature is not that good. Compiler won't complain if no values are provided.
@@VoroninPavel perhaps. But I personally believe that this shouldn't be something the compiler should catch. I think it should be up to the function writer to check the collection and throw an exception if empty wasn't allowed. But perhaps if the syntax is clean and clear enough, maybe the compiler could be made to catch this? Would it only work using params though? What about a function that takes in a collection without using params? Should there be syntax to omit empty collections in this case? Just not sure on the benefits (and edge cases) of that over the dev just throwing an exception.
@@VoroninPavel object state validation is not the concern of the language or method signature. That is a developer concern, and you need to provide proper object validation for your use case.
@@pharoah327 Well, there were some languages (experimental?) where collection type could include the length information, so arrays of different length are incompatible, but CLR type system is not that powerful. While run-time checks are necessary, it's always better to fail at compile-time.
If we talk DDD, constraints should come with the type. When we require non-empty collection, neither array nor list should be used in the first place, then we have a clear contract and compile-time safety.
But for low-level things this would be overkill, so I'd just be careful with 'params' not to make things worse by promoting illegal calls. I check that array against null anyway ;-)
It puzzles me - why they even spend time on "features" like that.. who needs this anyways. I wish they would focus more on some really useful stuff. Like DUs for example.
Performance, for example if they added span support to Console.WriteLine then you'd pretty much not have any memory allocation on any logging code.
It looks nice, but I will mostlikely never use it.
You are funny, "You" don't use the params anymore....
To me all these features despite being cool are actually not worthy of learning since new C# versions are incompatible with older ones. We have been running quite a large project consisting of 50+ subprojects, and I was so disapointed when it turned out that library compiled with new functions will not work with .net framework 4.8 or earlier. This is very confusing how fast .Net framework has been outdated because they put all the efforts into .Net core and how fast even .net core versions getting deprecated.
It'd be nice to have kwarg like python
It's funny because most recent features make C# more similar to Python. I'm wondering whether this aligns with any of Microsoft's plans regarding data science workloads.
@@marcotroster8247I hope they don't fly too close to the sun on this one, because some of the things Python does is just outright stupid.
Yeah I hate it. You can't tell the method only has one parameter.
Borrowed from old visual basic
I don't like the params feature! I hate autom. conversions, like in shitty JavaScript!
You are not obligated to use it. But a big difference is that this is all translated at compile time, and thus creates efficient binaries.
Or even more efficient than what you write yourself actually.
In JavaScript things more often tend to be opposite. Although even there you still should not try to be too much smarter than V8 actually. You can really easily make incorrect assumptions. Personally I tend to work with a programming language, not against it. Compilers and runtimes are really smart these days.
@@jongeduardBut others use these unnecessary features and nobody can read and understand that creepy code. See what happened to c++. 🤮
@@TheOnlyDominik Are you just referring to the C variadic functions? That's basically as old as both languages, even the printf function uses it.
And yes it may not be the nicest thing ever invented, but C is really quite a primitive language and so is it in C++ since it just took it over from C.
Actually I think for C terms this was kinda revolutionary to be honest. Not too many things with variable length can be implemented that easily in C.
Or are you referring to something else in C++ that I don't know about? I haven't been following everything from C++ last years anymore. I am currently really focused on C# and Rust.
I really like your content. But please speak slower. It can be hard to understand your accent.
My only complaint!