171–180 of 215 posts
So they finally took all of the cool features from F#. What's missing? The pipe operator for railway oriented programming?
type providers, units of measure, active patterns, complete type inference. Not sure I would want the last thing in C#, I think having boundaries at the function signature for that.
It's very disappointing that they aren't supporting Rust-style discriminated unions.
Earlier quoted context omitted.
> C# is a nightmare of language identities - a jack of all trades, master of none, choose your dialect language. I honestly have no idea where you would get this idea from. C# is a pretty opinionated language and it's worst faults all come from version 1.0 where it was mostly a clone of Java. They've been very carefully undoing that for years now. It's a far more comfortable and strict language now than before.
I can see where he's coming from. For example, `dynamic` was initially introduced to support COM interop when Office add-in functionality was introduced. Should I use it in my web API? I can, but I probably shouldn't. `.ConfigureAwait(bool)` is another where it is relevant, but only in some contexts. This is precisely because the language itself operates in many runtime scenarios.
This inspired the invokedynamic bytecode in the JVM, which has brought many benefits and much more use than the original .NET features, e.g. how lambdas get generated.
Earlier quoted context omitted.
You aren’t giving enough credit to the careful evaluation of how this adaption is happening. So far everything that was added to C# very much reduces the amount of dead boilerplate code other languages struggle with. Really give it an honest try before you judge it based on the summation of headlines.
In isolation, yes, I agree with you. But in the context of the cornucopia of other "carefully evaluated" features mixed into the melting pot, C# is a nightmare of language identities - a jack of all trades, master of none, choose your dialect language. No thanks.
Earlier quoted context omitted.
In isolation, yes, I agree with you. But in the context of the cornucopia of other "carefully evaluated" features mixed into the melting pot, C# is a nightmare of language identities - a jack of all trades, master of none, choose your dialect language. No thanks.
>a jack of all trades Yes, C# is a jack of all trades and can be used at many things. Web, desktop mobile, microservices, CLI, embedded software, games. Probably is not fitted for writing operating systems kernels due to the GC but most areas can be tackled with C#.
Is this the last of the F# features to be migrated into C#? What a missed opportunity. I think really F# if you combine all of its features, and what it left out, was the way. Pulling them all into C# just makes C# seem like a big bag of stuff, with no direction. F#'s features, and also what it did not included, gave it a style and 'terseness', that still can't really be done in C#. I don't really get it. Was a funct…
Absolutely agree. Modern C# language design feels very much lacking in vision or direction. It's mostly a bunch of shiny-looking language features being bolted on, all in ways that make the language massively more complex. Just look at this feature: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... Was this needed? Was this necessary ? It's reusing an existing keyword, fine. It's not hard to understand.…
Earlier quoted context omitted.
I'm 100% on board with the [] syntax. I'm not on board with adding the syntax for passing arguments to the constructor within that syntax. I agree that = [] is perfectly fine syntax. But I would definitely argue that: [with(capacity: values.Length * 2), .. is non-intuitive and unnecessary. What other language is there that has this syntax? Alternatively, is this a natural way of writing this? I wouldn't say so. My ma…
Hi there. Designer of this feature :D > is non-intuitive and unnecessary. intuitive is definitely in the eye of the beholder. When people saw: `HashSet people = [with(StringComparer.CaseInsensitiveComparer), .. group1, group2]` they found it understandable. And this was also much nicer than what they'd have to write today (which would bring them out of the nice declarative collection-expression space). Does that make…
C# doesn't need to have syntax sugar for every possible use case.
Some of the more recent features feel like the outcome of the team pressure to have new language features to announce in November every year.
Earlier quoted context omitted.
These are discriminated unions, even if they may be not Rust-style. You can see in the examples, how "switch" uses the implicit discriminant of the union to select the code branch that must be executed, depending on the current type of the value stored in an union. The syntax of the "switch" seems acceptable, without too many superfluous elements. It could have been made slightly better, by not needing dummy variable…
I don't think these are discriminated. From the docs: > Union types — exhaustive matching over a closed set of types > Closed hierarchies — exhaustive matching over a sealed class hierarchy > Closed enums — exhaustive matching over a fixed set of enum values I believe the last one would be sum types (disc. unions). This one allows overlapping types.
This is in contrast with what is called "union" in the C language, where you must know a priori the type of a value in order to use it correctly.
Moreover, if you can discriminate at run time which is the actual type, that means that you can discriminate between values that happen to have the same representation, but which come from distinct types, e.g. if you had a union between "signed integer" and "unsigned integer", you could discriminate between a signed "3" and an unsigned "3".
This property ensures that the number of possible values for a discriminated union type is the sum of the numbers of possible values for the component types, hence the alternative name "sum type", unlike for a non-discriminated union, where the number of possible values is smaller, because from the sum you must subtract the number of possible values of the intersection sets.
The C# unions described in the article are discriminated unions, except that their component types are not the types literally listed in their definition. If some of the component types are optional, than the true union components are the corresponding non-optional types, together with the null a.k.a. void type, which I find as a rather strange choice.
Earlier quoted context omitted.
You are looking at it from what you know about C#, the goal is how can you reduce (delete) all this to make the language more accessible. For you it may be fine to write: List strs = new List (); And sure if you have been using C# for years you know all the things going on here. But it shouldn’t be an argument that: List strs = []; Is substentionally easier to grasp. And that has been the theme of all changes. The ex…
That's a basic example with a single level of generics too, you'd sometimes have to do things like: Dictionary >> foo = new Dictionary >> Or things like: Dictionary >> foo = DoSomeWork(); And you'd have to get the type right, even though the compiler knew the type, because it'd tell you off for getting it wrong. Sometimes it was easiest to just grab the type from the compiler error. ( This example is of course a bit…