Looks like it's "just" type-erasure / syntactical sugar. E.g. value types are boxed.
Union types in C# 15
51–60 of 215 posts
Re: Union types in C# 15
#52Is 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…
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.
Re: Union types in C# 15
#53Earlier quoted context omitted.
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.…
> Try teaching someone C# nowadays. Completely impossible. That isn't a reasonable take. Failing to teach a language by enumerating all its features is an indictment of the instructor and not the language.
I guess I overdramatized the situation a bit :) It's a passionate topic for me; as somebody who has been using C# at work for 10 years now, I'm just not happy with the direction the language has been taking.
You're right, it's not impossible and in general it's not among the hardest languages to teach. But I would argue, it is heading that way.
There are already so many ways to do things in C#. For example, try explaining the difference between fields and properties; sounds easy, but making it really stick is quite a challenge. And that's one of the simplest cases (and a feature I'm 100% in favor of).
And you will have to explain it at some point, because real codebases contain these features so at some point, it'll need to be taught. Learning a language doesn't stop when you can write a simple application, it continues up until at least you're comfortable with most of its features and their practical use. The quicker one can get people to that point, the easier the language is to teach, I'd argue.
One might also argue that learning never really stops, but that's beside the point :)
In general, my issue isn't any specific feature. C# has many features that are non-trivial to learn but still great: value types, generics, expression trees. Source generators are relatively new and I like them! I like most of the things they're doing in the standard library or the runtime. Spans everywhere is a nice improvement, most new APIs are sensible and nice to use and the runtime just keeps getting faster every release. Great. It's more the pure C# language side I have an issue with.
But every language has a budget of innovation and cognitive load that you can expect people to deal with, and C# is not using its budget very wisely in my opinion.
Re: Union types in C# 15
#54Looks like it's "just" type-erasure / syntactical sugar. E.g. value types are boxed.
Yes, but see the section on custom unions* - you can write non-boxing unions/generators.
* https://devblogs.microsoft.com/dotnet/csharp-15-union-types/...
Re: Union types in C# 15
#55Earlier 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…
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…
Isn't this just another form of Python's list comprehensions?
https://docs.python.org/3/tutorial/datastructures.html#list-...
I'm also not sure that something not being intuitive or natural is necessarily a bad thing in of itself. You state it as if it's so, but you haven't demonstrated that this way of defining a list is worse. You also haven't made any attempt to understand any possible benefit, nor have you attempted any sort of analysis comparing the good and the bad aspects.
Re: Union types in C# 15
#56This is HUGE! Now we can use mostly functional programming in C#. This feature was requested since many years ago.
The only thing I wish now is for someone to build a functional Web framework for C#.
Re: Union types in C# 15
#57Is 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…
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.
> reduces the amount of dead boilerplate code other languages struggle with.
given that most of the thinks added seem more inspired by other languages then "moved over" from F# the "other languages struggle with" part makes not that much sense
like some languages which had been ahead of C# and made union type a "expected general purpose" feature of "some kind":
- Java: sealed interfaces (on high level the same this C# features, details differ)
- Rust: it's enum type (but better at reducing boilerplate due to not needing to define a separate type per variant, but being able to do so if you need to)
- TypeScript: untagged sum types + literal types => tagged sum types
- C++: std::variant (let's ignore raw union usage, that is more a landmine then a feature)
either way, grate to have it, it's really convenient to represent a `TYPE is either of TYPES` relationship. Which are conceptually very common and working around them without proper type system support is annoying (but very viable).
I also would say that while it is often associated with functional programing it has become generally expected even if you language isn't functional. Comparable to e.g. having some limited closure support.
Re: Union types in C# 15
#58Is 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…
>Is this the last of the F# features to be migrated into C#?
>What a missed opportunity.
Not adding functional features to F# doesn't mean F# would have gained more usage. And if someone wants to use F#, no one is stopping him or her.
Re: Union types in C# 15
#59Looks like it's "just" type-erasure / syntactical sugar. E.g. value types are boxed.
Yes, but that's just the default behavior. You can implement your own non-boxing version for performance critical applications.
Re: Union types in C# 15
#60Earlier 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…
Isn't this just another form of Python's list comprehensions? https://docs.python.org/3/tutorial/datastructures.html#list-... I'm also not sure that something not being intuitive or natural is necessarily a bad thing in of itself. You state it as if it's so, but you haven't demonstrated that this way of defining a list is worse. You also haven't made any attempt to understand any possible benefit, nor have you attemp…
No, this is just a constructor call, it's purely syntax sugar for the new() way of doing it.
> I'm also not sure that something not being intuitive or natural is necessarily a bad thing in of itself. You state it as if it's so, but you haven't demonstrated that this way of defining a list is worse.
I would argue that a language having more features, without the feature being helpful, is a bad thing in itself. If the syntax isn't necessary or very convenient in many cases, it shouldn't exist. The syntax being natural (which, absolutely, is a very subjective thing) just makes it less of an issue, I'd say.
Every new syntax added to the language adds cognitive overhead to readers of code. But also, it adds possible interactions with other language features that may be added in the future. Now, the example I brought up doesn't really concern the second point, I'll concede that. But unions? That is a big concept to add to a language that already has decades of existing conventions and tons of other features. How will they interact with generics? Nullable reference types? And, just as importantly: How will they interact with any other features that might be added at some point that we don't even know about?
I'm not against adding syntax sugar. For example, I quite like primary constructors, which is another relatively new C# feature. I think it's a bit annoying that they were kind of added in a roundabout way, by first adding records and then adding primary constructors to classes, but this time they don't define properties but fields...but in the end, it's a nice convenience feature when using constructor injection. Which, whatever one may feel about this, is pretty common in C# code.
But the thing is: If every single feature that's nice for a few use cases gets added to a language, the language will explode. The best example for this is C++. C# is definitely not that bad, far from it, but my point is that I want it to stay that way :)