Looks like it's "just" type-erasure / syntactical sugar. E.g. value types are boxed.
Here is visual layout if anyone is interested - https://vectree.io/c/memory-layout-tagging-and-payload-overl...
81–90 of 215 posts
Looks like it's "just" type-erasure / syntactical sugar. E.g. value types are boxed.
Here is visual layout if anyone is interested - https://vectree.io/c/memory-layout-tagging-and-payload-overl...
Is C# a great language trapped in a terrible ecosystem? ie would masses use C# if it existed in another ecosystem? Or is it becoming a ball-of-mud/bad language compared to its contemporaries? (Honest questions. I have never used .NET much. I'm curious)
C# is a language that serves many masters and if you trace the origin of its featureset, you can see why each was created. Take the `dynamic` keyword: created to support interfacing with COM interop easier[0]. It serves many audiences so it can feel like the language is a jack of all trades and master of none (because it is) and because it is largely backwards compatible over its 20+ years of existence. That said, I…
Earlier quoted context omitted.
Third paragraph from the top: > unions enable designs that traditional hierarchies can’t express, composing any combination of existing types into a single, compiler-verified contract.
It's very unclear which you mean by that. To me that "compiler-verified" maps to "sealed", not "on the fly". Probably. Their example is: public union Pet(Cat, Dog, Bird); Pet pet = new Cat("Whiskers"); - the union type is declared upfront, as is usually the case in c#. And the types that it contains are a fixed set in that declaration. Meaning "sealed" ?
Looks 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/...
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.…
I don't love OneOrMore It's trying to generalize - we might have exactly one T, fine, or a collection of T, and that's more T... except no, the collection might be zero of them, not at least one and so our type is really "OneOrMoreOrNone" and wow, that's just maybe some T.
You are free to call it `public union Some(T, IEnumerable)`
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#.
Midori would like to have a word with you:
Earlier quoted context omitted.
I meant code generators like sqlc
Then this goes back to your question: > Is it good at the wrong thing? No, it's good at the right thing which is allowing developers to write type-safe SQL queries using C# at the application layer versus writing SQL that gets translated into C#.
I don't love OneOrMore It's trying to generalize - we might have exactly one T, fine, or a collection of T, and that's more T... except no, the collection might be zero of them, not at least one and so our type is really "OneOrMoreOrNone" and wow, that's just maybe some T.
So IEnumerable ? What's up with wrapping everything into fancy types just to arrive at the exact same place.
Earlier quoted context omitted.
> Pulling them all into C# just makes C# seem like a big bag of stuff, with no direction. Agreed. Java is on the same trail.
Care to elaborate? I think Java is showing remarkable vision and cohesion in their roadmap. Their released features are forward compatible and integrate nicely into existing syntax. I work much with C# these days and wish C# had as cohesive a syntax story. It often feels like "island of special syntax that makes you fall of a cliff".