13 ms·
New in C# 10: Easier Lambda Expressions
- tester756 5y agoNice, I like it. I do wonder what was limiting them before
- ygra 5y agoEvery feature starts out with -100 points. So there's always a trade-off to do everything you can imagine to make every last corner case nice or shipping something in a reasonable timeframe. When lambda expressions were introduced they were designed to work well together with LINQ and that whole part of the language isn't a small one either. Storing a lambda expression in a local variable is not such a common occurrence to really need type inference or the ability to add types to lambda expressions. Heck, I'd say, by now with local functions most lambdas that previously would have been a local could now just be a local function.
- kevingadd 5y agoYeah, while I run into the sharp edges that this feature addresses on a regular basis, it typically only costs me a small amount of typing to fix, and it's not that frequent. So it's nice to have but totally reasonable that they never got around to it before.
- jayd16 5y agoThey added an explicit return type, which allows for the full delegate type to be inferred.
- agluszak 5y agoThere's something clearly wrong with the code samples: look at the </string> "closing tags" which somehow sneaked in in line 17 of the first sample
- FairDune 5y agoYeah, I tried those out in a scratch pad. They don't compile.
- Sharlin 5y agoSeems the renderer has "helpfully" added closing tags for the `<string ...>` generic parameter lists since they look like *ml...
- mastax 5y agoThe markdown parser of the "Reddit Sync" app adds closing tags to things as well. Hasn't been annoying enough for me to switch.
- thrower123 5y agoF# is really, really bleeding into C#. There'll be a convergence, for all intents and purposes, by about C# 15 at this rate.
- paavohtl 5y agoEhhh, not really. It really depends on what you mean by convergence. You could add every single one of F#'s features into C#, and I still wouldn't consider them to be same language or the other to be irrelevant. The strength of F# is the primary coding style: mostly functional, mostly immutable, expression-based, strongly typed with global type inference. The way most C# is written is almost the polar opposite: mostly OOP/imperative, mostly mutable, statement-based, statically typed but with a less expressive type system (no sum types, exceptions and nulls over Result and Option) and very limited local type inference. The F# style is enabled by a set of features - some of which would be really hard to add to C# (such as currying and global type inference) - but even if they were added, the millions(?) of C# developers would be unlikely adopt the functional style just because it was possible. A language is not just a list of features; each language has its own culture and "idiomatic" way of doing things.
- iddan 5y agoLook at JavaScript though. A few years back it was all about loose typing, mutation, OOP (with prototype), etc and now TypeScript is king, React and Rx are promoting functional idioms (immutability, purity). So I think that can teach us that when a language can be typed and functional there could be a vibrant community that uses it that way while there’s another that doesn’t
- spaetzleesser 5y agoIs F# still moving forward? I am tempted to try it but I don’t want to bet on another tool MS may abandon soon like they did with the .NET frameworks.
- munchler 5y agoYes. F# 6 was just released with .NET 6 and Visual Studio 2022. It's an awesome language with a vibrant community. Plus, it's fully open source and cross-platform, so if MS were to abandon it, I think it could carry on anyway.
- jayd16 5y agoHere's a link to the official summary. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-10.0/lambda-improvements https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... Lambdas can also have attributes now, too.
- oneepic 5y agoWith this the language gets a little more beautiful. On a related note, I just switched from a C# job at Microsoft (microservices) and moved to a Java shop where we're all really just starting to learn Kotlin and migrate our work there. I'm shocked how many times we've learned a fancy feature and I get to say, "actually, C# has something just like this too." (i.e. operator overloading) It is a surprisingly modern language keeping up with the other ones.
- moritonal 5y agoErr.. I'm too drunk to check, bit I'm fairly sure C# has had operator overloading for like ten years? Having worked recently in it, I found Java to be relatively (as a language, not for tooling) backwards compared to C#.
- nkozyra 5y agoI think that's what the poster you're replying to is saying.
- oneepic 5y agoNo, the reply raises a valid issue. I was implying that op overloading was a modern thing, but it's apparently been around for a very long time, and doesn't seem to be the best example of a "modern" feature of languages.
- thrower123 5y agoC++ had operator overloading in the 90s. Mostly we decided it was a bad idea. Every generation must learn this for themselves though.
- Guvante 5y agoExcept C++ didn't learn that operator overloading is bad. C++ learned that operator overloading for everything was bad. The language kind of put itself into a corner when what C# calls `MoveNext` is called `++` (with two variants of course) and what C# calls `Current` is called `*`. Taking what mathematically worked for iterating an array and taking it piecemeal to define your syntax is the kind of operator overloading that is a bad idea.
- pipeline_peak 5y agoI love watching C# slowly grow from a boring MS Java clone into something elegant but still useful
- ShinTakuya 5y agoI think it's been elegant for a number of years now. Pretty much ever since Linq became usable.
- pipeline_peak 5y agoYeah, lambdas and reflection really.
- vips7L 5y agoPersonally I think reflection is the devil and the reason why we can’t abandon VMs for native compilers.
- pipeline_peak 5y agoReflection does away the need to manually implement serializers. In a growing codebase where data models transform and references to those models begin to rot, that is incredibly useful.
- vips7L 5y agoThat can be done with code generation at compile time. We don’t need to reflect at runtime for that.
- Const-me 5y agoUsability is worse, IMO. Serialization libraries need to be decoupled from the records being serialized. These two things are compiled into different assemblies, and often written by different people. Still possible to replace with compile time codegen, but the implementation gonna be complicated and fragile.
- deleted 5y ago[deleted]
- brundolf 5y agoA couple decades ago everyone was on static types. But then people got sick of the boilerplate, and in what I think was a backlash, dynamic languages like JavaScript, Python, Ruby, etc. took the world by storm. With the raised bar of developer expectations when it comes to agility, static type systems were forced to innovate, and now type-inference and related features are coming to all static languages and bringing us back around to a best-of-both worlds situation. Exciting times.
- agumonkey 5y agoWhat you see as innovation is just slow diffusion into mainstream, the last decade is basically 80s sml family. The funny .. or sad.. part is that the c#9 explicit ~verbose style would have been the only one accepted before. If you wrote implicitely typed variables people would get angry (I think there are many online articles about how java 9 `var` was bad)
- brundolf 5y ago> What you see as innovation is just slow diffusion into mainstream It can be both. Type inference isn't a brand-new idea, but it still takes work to diffuse it into mainstream, practical languages, especially retrofitting it onto existing languages that weren't designed for it. That still counts as innovation in my book.
- agumonkey 5y agoYeah fair point. I'm just a bit salty that a lot of people only see the late stage effect onto their language and might assume that it came out of a vacuum you know. Then they look at you weird with your scheme, sml and prologs. Alas
- spaetzleesser 5y agoI love type inference. Strong typing makes maintenance and refactoring much easier and with type inference the code looks very good. I still remember how ugly and tedious STL iterators were in C++. Now it’s just “auto”. LINQ also wouldn’t work without type inference.
- DeathArrow 5y agoC# 10 didn't introduce many new features. I hate they delayed the introduction of Algebraic Data Types again. Maybe they will appear in C# 11. Using ADT in F# makes it a breeze to do domain modeling.
- dgellow 5y agoC#10 brings some nice quality of life, which is always welcomed. Not all releases have to be about huge changes. For example file scoped namespace is a very simple but great change, improvement for lambdas, improvement for structs, all of this make it nicer and simpler to write readable code. Edit: I would also love to see ADT in C#!
- sirwhinesalot 5y agoRecord classes and pattern matching get you 90% of the way there thankfully. Not perfect, but good enough. It's funny how much of a difference being able to write each case in a single line and have equality and all that stuff automatically taken care of makes. Honestly that's more important than the exhaustive pattern matching you get with ADTs. I can live with "default: throw".
- dgellow 5y agoIf you haven’t yet, check out the C#10 blog post, it has details covering all the changes: https://devblogs.microsoft.com/dotnet/welcome-to-csharp-10/ https://devblogs.microsoft.com/dotnet/welcome-to-csharp-10/. This version brings quality of life changes that make it simpler and nicer to write readable code, which is great to see IMHO.
- stevefan1999 5y agoI love how this make MapGet/MapPost/MapPut and such useless, and we can just have one MapAction to run them all. I hope .NET 6 would be getting more and more attention and competitive against Java. Java's language and syntax, it's so bad right now.
- pattrn 5y agoI love how the second to last code sample has three closing </string> tags, and the blog name is "don't code tired." (Also, really looking forward to using the new type inference.)