Other languages have unions with named choices, where each name selects a type and the types are not necessarily all different. Rust, Haskell, Lean4, and even plain C unions are in this category (although plain C unions are not discriminated at all, so they’re not nearly as convenient).
I personally much prefer the latter design.
If you're interested, i can point you to specs i'm writing that address the area you care about :)
The only thing I wish now is for someone to build a functional Web framework for 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 functional approach really so 'difficult'? That it didn't continue to grow and takeover.
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.
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)
I've seen exactly one Rust type which is actually a union, and it's a pretty good justification for the existence of this feature, but one isn't really enough. That type is MaybeUninit<T> which is a union of a T and the empty tuple. Very, very, clever and valuable, but I didn't run into any similarly good uses outside that.
Better than a new language for each task, like you have with Go (microservices) and Dart (GUI).
I'm using F# on a personal project and while it is a great language I think the syntax can be less readable than that of C#. C# code can contain a bit too much boilerplate keywords, but it has a clear structure. Lack of parenthesis in F# make it harder to grasp the structure of the code at a glance.
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.
also called general purpose, general style langue
> that still can't really be done in C#
I would think about it more as them including features other more general purpose languages with a "general" style have adopted then "migrating F# features into C#, as you have mentioned there are major differences between how C# and F# do discriminated sum types.
I.e. it look more like it got inspired by it's competition like e.g. Java (via. sealed interface), Rust (via. enum), TypeScript (via structural typing & literal types) etc.
> Was a functional approach really so 'difficult'?
it was never difficult to use
but it was very different in most aspects
which makes it difficult to push, sell, adapt etc.
that the maybe most wide used functional language (Haskel) has a very bad reputation about being unnecessary complicated and obscure to use with a lot of CS-terminology/pseudo-elitism gate keeping doesn't exactly help. (Also to be clear I'm not saying it has this properties, but it has the reputation, or at least had that reputation for a long time)
Agreed. Java is on the same trail.
Active patterns, computation expressions, structural typing, statically resolved type parameters, explicit inlining, function composition, structural equality, custom operators and much richer generators.
Not sure I would want the last thing in C#, I think having boundaries at the function signature for that.
Sure, but the comparable Rust feature is enum, not union.
You are free to call it `public union Some<T>(T, IEnumerable<T>)`
> I don't really get it
To me it makes sense because C# is a very general purpose language that has many audiences. Desktop GUI apps, web APIs, a scripting engine for gaming SDKs, console apps.It does each reasonably well (with web APIs being where I think they truly shine).
> Was a functional approach really so 'difficult'
It is surprisingly difficult for folks to grasp functional techniques and even writing code that uses `Func`, `Action`, and delegates. Devs have no problem consuming such code, but writing such code is a different matter altogether; there is just very little training for devs to think functionally. Even after explaining why devs might want to write such code (e.g. makes testing much easier), it happens very, very rarely in our codebase.Note that most of its development is still by the open source community and its tooling is an outsider for Visual Studio, where everything else is shared between Visual Basic and C#.
With the official deprecation of VB, and C++/CLI, even though the community keeps going with F#, CLR has changed meaning to C# Language Runtime, for all practical purposes.
Also UWP never officially supported F#, although you could get it running with some hacks.
Similarly with ongoing Native AOT, there are some F# features that break under AOT and might never be rewritten.
A lost opportunity indeed.
In the article, the example with the switch works because it switches on the class of the instance.
That is essentially the motivation, primarily in the context of FFI where matching C's union behaviour using transmute is tricky and error-prone.
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. But it adds a new syntax to a language that's already filled to the brim, just to save a few keystrokes?
Try teaching someone C# nowadays. Completely impossible. Really, I wish they would've given F# just a tenth of the love that C# got over the years. It has issues but it could've been so much more.
https://hackage.haskell.org/package/oneormore or scala: https://typelevel.org/cats/datatypes/nel.html
it's for type purists, because sometimes you want the first element of the list but if you do that you will get T? which is stupid if you know that the list always holds an element, because now you need to have an unnecessary assertion to "fix" the type.
But I do agree. C# is heading to a weird place. At first glance C# looks like a very explicit language, but then you have all the hidden magical tricks: you can't even tell if a (x) => x will be a Func or Expression[0], or if a $"{x}"[1] will actually be evaluated, without looking at the callee's signature.
[0]: https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...
[1]: https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...
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.
C# / .NET Principal Content developer
Union types have been frequently requested for C#, and they’re here. Starting with .NET 11 Preview 2, C# 15 introduces the union keyword. The union keyword declares that a value is exactly one of a fixed set of types with compiler-enforced exhaustive pattern matching. If you’ve used discriminated unions in F# or similar features in other languages, you’ll feel right at home. But C# unions are designed for a C#-native experience: they’re type unions that compose existing types, integrate with the pattern matching you already know, and work seamlessly with the rest of the language.
Before C# 15, when a method needs to return one of several possible types, you had imperfect options. Using object placed no constraints on what types are actually stored — any type could end up there, and the caller had to write defensive logic for unexpected values. Marker interfaces and abstract base classes were better because they restrict the set of types, but they can’t be “closed” — anyone can implement the interface or derive from the base class, so the compiler can never consider the set complete. And both approaches require the types to share a common ancestor, which doesn’t work when you wanted a union of unrelated types like string and Exception, or int and IEnumerable<T>.
Union types solve these problems. A union declares a closed set of case types — they don’t need to be related to each other, and no other types can be added. The compiler guarantees that switch expressions handling the union are exhaustive, covering every case type without needing a discard _ or default branch. But it’s more than exhaustiveness: unions enable designs that traditional hierarchies can’t express, composing any combination of existing types into a single, compiler-verified contract.
Here’s the simplest declaration:
public record class Cat(string Name);
public record class Dog(string Name);
public record class Bird(string Name);
public union Pet(Cat, Dog, Bird);
This single line declares Pet as a new type whose variables can hold a Cat, a Dog, or a Bird. The compiler provides implicit conversions from each case type, so you can assign any of them directly:
Pet pet = new Dog("Rex");
Console.WriteLine(pet.Value); // Dog { Name = Rex }
Pet pet2 = new Cat("Whiskers");
Console.WriteLine(pet2.Value); // Cat { Name = Whiskers }
The compiler issues an error if you assign an instance of a type that isn’t one of the case types to a Pet object.
The When you use an instance of a union type known to be not null, the compiler knows the complete set of case types, so a switch expression that covers all of them is exhaustive— no discard needed:
string name = pet switch
{
Dog d => d.Name,
Cat c => c.Name,
Bird b => b.Name,
};
The types Dog, Cat, and Bird are all non-nullable types. The pet variable is known to be non-null, it was set in the earlier snippet. Therefore, this switch expression isn’t required to check for null. If any of the types are nullable, for example int? or Bird?, all switch expressions for a Pet instance would need a null arm for exhaustiveness. If you later add a fourth case type to Pet, every switch expression that doesn’t handle it produces a compiler warning. That’s one core value: the compiler catches missing cases at build time, not at runtime.
Patterns apply to the union’s Value property, not the union struct itself. This “unwrapping” is automatic — you write Dog d and the compiler checks Value for you. The two exceptions are var and _, which apply to the union value itself so you can capture or ignore the whole union.
For union types, the null pattern checks whether Value is null. The default value of a union struct has a null Value:
Pet pet = default;
var description = pet switch
{
Dog d => d.Name,
Cat c => c.Name,
Bird b => b.Name,
null => "no pet",
};
// description is "no pet"
The Pet example illustrates the syntax. Now, let’s explore real world scenarios for union types.
APIs sometimes accept either a single item or a collection. A union with a body lets you add helper members alongside the case types. The OneOrMore<T> declaration includes an AsEnumerable() method directly in the union body — just like you’d add methods to any type declaration:
public union OneOrMore<T>(T, IEnumerable<T>)
{
public IEnumerable<T> AsEnumerable() => Value switch
{
T single => [single],
IEnumerable<T> multiple => multiple,
null => []
};
}
Notice that the AsEnumerable method must handle the case where Value is null. That’s because the default null-state of the Value property is maybe-null. This rule is necessary to provide proper warnings for arrays of a union type, or instances of the default value for the union struct.
Callers pass whichever form is convenient, and AsEnumerable() normalizes it:
OneOrMore<string> tags = "dotnet";
OneOrMore<string> moreTags = new[] { "csharp", "unions", "preview" };
foreach (var tag in tags.AsEnumerable())
Console.Write($"[{tag}] ");
// [dotnet]
foreach (var tag in moreTags.AsEnumerable())
Console.Write($"[{tag}] ");
// [csharp] [unions] [preview]
The union declaration is an opinionated shorthand. The compiler generates a struct with a constructor for each case type and a Value property of type object? that holds the underlying value. The constructors enable implicit conversions from any of the case types to the union type. The union instance always stores its contents as a single object? reference and boxes value types. That covers the majority of use cases cleanly.
But several community libraries already provide union-like types with their own storage strategies. Those libraries don’t need to switch to the union syntax to benefit from C# 15. Any class or struct with a [System.Runtime.CompilerServices.Union] attribute is recognized as a union type, as long as it follows the basic union pattern: one or more public single-parameter constructors (defining the case types) and a public Value property.
For performance-sensitive scenarios where case types include value types, libraries can also implement the non-boxing access pattern by adding a HasValue property and TryGetValue methods. This lets the compiler implement pattern matching without boxing.
For full details on creating custom union types and the non-boxing access pattern, see the union types language reference.
Union types give you a type that contains one of a closed set of types. Two proposed features provide related functionality for type hierarchies and enumerations. You can learn about both proposals and how they relate to unions by reading the feature specifications:
closed modifier on a class prevents derived classes from being declared outside the defining assembly.closed enum prevents creation of values other than the declared members.Together, these three features give C# a comprehensive exhaustiveness story:
Union types are available now in preview. When evaluating them, keep this broader roadmap in mind. These proposals are active, but aren’t yet committed to a release. Join the discussion as we continue the design and implementation of them.
Union types are available starting with .NET 11 Preview 2. To get started:
net11.0.<LangVersion>preview</LangVersion> in your project file.IDE support in Visual Studio will be available in the next Visual Studio Insiders build. It is included in the latest C# DevKit Insiders build.
Early preview: declare runtime types yourself
In .NET 11 Preview 2, the UnionAttribute and IUnion interface aren’t included in the runtime yet. You must declare them in your project. Later preview versions will include these types in the runtime.
Add the following to your project (or grab RuntimePolyfill.cs from the docs repo):
namespace System.Runtime.CompilerServices
{
[AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
AllowMultiple = false)]
public sealed class UnionAttribute : Attribute;
public interface IUnion
{
object? Value { get; }
}
}
Once those are in place, you can declare and use union types:
public record class Cat(string Name);
public record class Dog(string Name);
public union Pet(Cat, Dog);
Pet pet = new Cat("Whiskers");
Console.WriteLine(pet switch
{
Cat c => $"Cat: {c.Name}",
Dog d => $"Dog: {d.Name}",
});
Some features from the full proposal specification aren’t yet implemented, including union member providers. Those are coming in future previews.
Union types are in preview, and your feedback directly shapes the final design. Try them in your projects, explore edge cases, and tell us what works and what doesn’t.
To learn more:
Category
Topics
C# / .NET Principal Content developer
Bill Wagner writes the docs for https://docs.microsoft.com/dotnet/csharp. His team is responsible for all the .NET content on docs.microsoft.com. He's also a member of the C# standardization committee.
https://github.com/manifold-systems/manifold/tree/master/man...
Also you can manually tag them and get s.th. more like other high level languages. It will just look ugly.
If I understand correctly, it’s actually OneOrOneOrMoreOrNone. Because you have two different distinguishable representations of “one”.
The only reason to use this would be if you typically have exactly one, and you want to avoid the overhead of an enumeration in that typical case. In other words, AnyNumberButOftenJustOne<T>.
So IEnumerable<T> ? What's up with wrapping everything into fancy types just to arrive at the exact same place.
In the places where that is a thing, I've never needed to care. (Which is kind of the point)
Do you actually have a datapoint of someone failing to understand C# or are you just hyperbolically saying its a big language? The tooling, the ecosystem, the linting, the frameworks. Its a very easy language to get into...
For you it may be fine to write:
List<string> strs = new List<string>();
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<string> strs = [];
Is substentionally easier to grasp.
And that has been the theme of all changes.
The example you point out is the advanced case, someone only needs in a very specific case. It does not have a lot todo with learning the language.
The language design team is really making sure that the features work well throughout and I think that does deserve some credit.
If they actually put effort in F#, it would have reached "unteachable" state already :)
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.
Yes and no. C# unions aren’t sealed types, that’s a separate feature. But they are strictly nominal - they must be formally declared:
union Foo(Bar, Baz);
Which isn’t at all the same as saying: Bar | Baz
It is the same as the night and day difference between tuples and nominal records.It has a bad rep because Microsoft could Microsoft as they do.
Are you sure? This is a feature of OCaml but not F# IIUIR
Edit: https://github.com/fsharp/fslang-suggestions/issues/538
The problem with ad-hoc unions is that without discipline, it invariably ends in a mess that is very, very hard to wrap your head around and often requires digging through several layers to understand the source types.
In TS codebases with heavy usage of utility types like `Pick`, `Omit`, or ad-hoc return types, it is often exceedingly difficult to know how to correctly work with a shape once you get closer to the boundary of the application (e.g. API or database interface since shapes must "materialize" at these layers). Where does this property come from? How do I get this value? I end up having to trace through several layers to understand how the shape I'm holding came to be because there's no discrete type to jump to.
This tends to lead to another behavior which is lack of documentation because there's no discrete type to attach documentation to; there's a "behavioral slop trigger" that happens with ad-hoc types, in my experience. The more it gets used, the more it gets abused, the harder it is to understand the intent of the data structures because much of the intent is now ad-hoc and lacking in forethought because (by its nature) it removes the requirement of forethought.
"I am here. I need this additional field or this additional type. I'll just add it."
This creates a kind of "type spaghetti" that makes code reuse very difficult.So even when I write TS and I have the option of using ad-hoc types and utility types, I almost always explicitly define the type. Same with types for props in React, Vue, etc; it is almost always better to just explicitly define the type, IME. You will thank yourself later; other devs will thank you.
=> named sum type implicitly tagged by it's variant types
but not "sealed", as in no artificial constraints like that the variant types need to be defined in the "same place" or "as variant type", they can be arbitrary nameable types
Here is visual layout if anyone is interested - https://vectree.io/c/memory-layout-tagging-and-payload-overl...
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.
Probably more this than any technical reason. More about culture and installed view points.
I don't want to get into the objects/function wars, but do think pretty much every technical problem can be solved better with functions. BUT, it would take an entire industries to re-tool. So think it was more about inertia.
Inertia won.
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 think people make a mountain out of a molehill with respect to keyword sprawl. Depending on what you're building, you really only need to focus on the slice of the language and platform you're working with. If you don't want to use certain language features...just don't use them?
I think it excels in a few areas: web APIs and EF Core being possibly the best ORM out there. For me, it is "just right". Excellent platform tooling, very stable platform, very good performance, hot reload (good, but not perfect), easy to pick up the language if you already know TypeScript[1]; there are many reasons it is a good language and platform.
[0] https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...
And you’re exactly right.
It’s not “one or more.”
It’s “one or not one.”
Need two or not two.
> unions enable designs that traditional hierarchies can’t express, composing any combination of existing types into a single, compiler-verified contract.
.NET is a fantastic ecosystem. Has a decent build and dependency system (NuGet, dotnet run/build, declarative builds in XML). Massive standard library, with a consistent and wide focus on correctness, ergonomics, and performance across the board.
You can write everything in many languages, all on the same runtime: business logic in C#; hot paths interfacing with native libraries in C++/CLI; shell wrappers in PowerShell, document attachments with VB, data pipelines in F#.
I feel more people should use it, or at least try it, but sadly it is saddled with the perception that it is Windows-only, which hasn't been true for a decade (also, IMO, not necessarily a negative, because Windows is a decent OS, sue me).
Are there particular things about the ecosystem that you worry about (or have heard about)? Biggest complaint I would have is that it seems like many popular open source libraries in the .NET ecosystem decide to go closed source and commercial once they get popular enough.
* https://devblogs.microsoft.com/dotnet/csharp-15-union-types/...
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".
Dictionary<string, List<Tuple<string, string>>> foo = new Dictionary<string, List<Tuple<string, string>>>
Or things like: Dictionary<string, List<Tuple<string, string>>> 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 OTT, and it's a bit of a code-smell to be exposing that detail of typing to consumers. )No-one wants to go back to that, and anyone who says C# is over-complicated I think is forgetting how rough it was in the earliest versions.
While introduction of auto-typing through "var" helped a lot with that, you'd still regularly have to fight if you wanted to properly initialise arrays with values, because the syntax was just not always obvious.
Collection literals are amazing, and now the ability to pass things into the constructor means they can be used when you need constructor parameters too, that's just a good thing as you say.
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.
I work on multiple applications with different versions of C# and/or Dotnet. I find it quite annoying to have to remember what syntax sugar is allowed in which versions.
If C# did not want verbose syntax, then Java was a poor choice to imitate.
But, that would takes, schools changing, companies changing, everything. So it was really the installed base that won, not what was better.
We'd have to go back in time, and have some ML Language win over C++ .
For example, C# chose not to go down the route of type erasure for the sake of generics and because of that you don't get the same sort of runtime type issues that Java might have.
VB.NET's Object was created to support interfacing with COM interop easier. VB.NET's one key niche versus C# for many early years was COM interop through Variant.
C#'s dynamic keyword was more directly added as a part of the DLR (Dynamic Language Runtime aka System.Dynamic) effort spurred by IronPython. It had the side benefit of making COM interop easier in C#, but the original purpose was better interop with IronPython, IronRuby, and any other DLR language. That's also why under the hood C#'s dynamic keyword supports a lot of DLR complexity/power. You can do a lot of really interesting things with `System.Dynamic.IDynamicMetaObjectProvider` [1]. The DLR's dependency on `System.Linq.Expressions` also points out to how much further in time the DLR was compared to VB.NET's Object which was "just" the VB7 rename of VB6 Variant originally (it did also pick up DLR support).
The DLR hasn't been invested into in a while, but it was really cool and a bit of an interesting "alternate universe" to still explore.
[0] https://learn.microsoft.com/en-us/dotnet/api/system.dynamic....
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 main language in my free time is Rust, a few years ago it was F#. So, I'm absolutely open to other syntax ideas. But I feel that there has to be a direction, things have to work together to make a language feel coherent.
Another example would be Clojure, which I started learning a few months ago (before we all got swept up in AI FOMO :D). Clojure as a language feels very coherent, very logical. I'm still a beginner, but every time I learn something about it, it just makes sense. It feels as if I could have guessed that it works this way. I don't get that feeling at all in many of the new features of C#.
> The example you point out is the advanced case, someone only needs in a very specific case. It does not have a lot todo with learning the language.
I disagree. When learning the language, you're going to have to read other people's code and understand it. It's the same basic principle, but, I'd argue, much worse in C++. Yes, in theory, you don't have to understand SFINAE and template metaprogramming and (now) concepts and all those things. You could just work in a subset of C++ that doesn't use those things. But in practice, you're always going to have issues if you don't.
This is exactly how C++ landed where it is now. Every time it's "you only need to know that syntax if..." well it ends up everyone has to know that syntax because someone will use it and if you're a responsible programmer you'll end up reading a lot code written from other people.
I would've loved an F# that found a way to improve on the performance issues, especially when using computation expressions. That and, either, a deeper integration of .NETs native OOP subtyping, or some form of OCaml-like module system, would have been enough to make it an almost perfect language for my tastes.
Obviously, these are big, and maybe impossible, issues. But Microsoft as a whole never really dedicated enough resources to find out. I feel for the people still working on it, their work is definitely appreciated :)
They could’ve done the Either type which would’ve been more correct or maybe EitherT (if the latter is even possible)
In my experience it does not work very well outside of the sanctioned Linux distributions. Quirky heisenbugs and nonsensical crashes made it virtually unusable for me on Void. I doubt that's changed in the years that have since passed.
> not necessarily a negative, because Windows is a decent OS
Is a language runtime worth an operating system? I think that's a paradigm we left behind in the 1970s when the two were effectively inseperable (and interwoven with hardware!) I wouldn't expect someone to swap to using a Unix system because they really want a better Haskell experience.
I just don't see any actual interesting or meaningful reasons to care about .NET, I effectively feel the same way about it that I do about Go. Just not something that solves any problem I have, and doesn't have anything that interests me. Although effectively I did try it, so it's a moot point considering that's one of the outcomes you're wishing for.
That's why I like it so much. And now, I can write mostly functional code.
>I think it excels in a few areas: web APIs and EF Core being possibly the best ORM out there
It's awesome for web stuff and microservices.
Is it good at the wrong thing? Eg compare to strongly-typed query generators
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" ?
(The amount of times I hear "the standard lib is great!" seems more to attempt to defend the plethora of commercial libraries, more than anything)
The community feels rather insular too? The 9-5 dayjob types with employers who don't understand or embrace open source? At my age I can respect that though
And is Postgresql a 2nd-class citizen? If so, your boss will tell you to use SQL Server surely?
I guess it's hard to get a grasp on the state/health of .NET as to me it seems 99.99999% of the code is in private repos companies, as it's not a popular choice for open source projects. Which itself seems like a proxy signal though
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.
We have been pushing toward higher performance for years and this is a performance pitfall for unions would are often thought of as being lighter weight than inheritance hierarchies.
F# just stores a field-per-case, with the optimization that cases with the same type are unified which is still type safe.
The only things that I wish for are: rusts borrow-checker and memory management. And the AOT story would be more natural.
Besides that, for me, it is the general purpose language.
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#.
But still there is a difference between learning and mastering.
I recently helped my partner learn for her CS class, and I feel very comfortable arguing that my previous statement holds up.
Mastering? No, in that case I agree with you.
… wait, I've made a different mistake here while trying to explain the difference, haven't I? I was describing it as a sum type, but it's not really a sum type, it's really just set-theoretic union, right?
Which also means OneOrMore is unsound in a different way because it doesn't guarantee that T and IEnumerable<T> are disjoint; OneOrMore<object> initialized from [x] will always return [[x]] from AsEnumerable, won't it? If I'm interpreting the switch expression correctly and the first case predominates, since a list is-an object? I don't have a test setup handy; someone with actual C# experience, please tell me whether that's correct or whether the compiler signals an error here or something…
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.
So is it a F# issue or inherent to functional programming?
> It's awesome for web stuff and microservices.
The gRPC platform support is top notch and seamless and Aspire is just :chefs_kiss:It is what it is but I wouldn't say its actually the fault of the language, especially now.
> And is Postgresql a 2nd-class citizen?
No, it is not.Microsoft maintains the Npgsql project[0] and I say that it is a very capable, feature rich adapter.
I have not used C# with SQL Server in almost a decade.
I expect the same will old here. But given the former group is multiple orders of magnitude higher than the latter, we tend to design the language in that order accordingly.
Trust me, we're very intersted in the low-overhead space as well. But it will be for more advanced users that can accept the tradeoffs involved.
And, in the meantime, we're designing it in C#15 that you can always roll the perfect implementation for your use case, and still be thought of as a union from teh language.
Midori would like to have a word with you:
`.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.
> 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 :)
Looking at it, the MS docs contain something about this exact topic, so maybe it's better nowadays: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
Sadly, I haven't used F# for years at this point so I can't speak to the current state.
(Dog, Cat) pet = new Cat();
So without defining the union with an explicit name beforehand.
"Never let perfect be the enemy of good"
Very much what I've seen from them over the years as they iterate and improve features and propagate it through the platform. AOT as an example; they ship the feature first and then incrementally move first party packages over to support it. Runtime `async` is another example.But I'm not sure that's really a problem. Does the OP expect everyone to use an entirely different languages every single context? I have web applications and desktop applications that interact with Office that share common code.
Even `dynamic` is pretty nice as far as weird dynamic language features are concerned.
Interestingly enough `.ConfigureAwait(bool)` is entirely the opposite of `dynamic` -- it's not a language feature at all but instead a library call. I could argue that might instead be better as a keyword.
var someUser = new { Name = "SideburnsOfDoom", CommentValue = 3 };
What type is `someUser` ? Not one that you can reference by name in code, it is "anonymous" in that regard. But the compiler knows the type.A type can be given at compile-time in a declaration, or generated at compile-time by the compiler like this. But it is still "Compiler-verified" and not ad-hoc or at runtime.
the type (Dog, Cat) pet seems similar, it's known at compile-time and won't change. A type without a usable name is still a type.
Is this "ad-hoc"? It depends entirely on what you mean by that.
> 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#.The reason I bring it up is that it is another one of those things where it matters in some cases depending on what you're doing.
Look at the depths that Toub had to go through to explain when to use it: https://devblogs.microsoft.com/dotnet/configureawait-faq/
David Fowl concludes in the comments:
> That’s correct, most of ASP.NET Core doesn’t use ConfigureAwait(false) and that was an explicit decision because it was deemed unnecessary. There are places where it is used though, like calls to bootstrap ASP.NET Core (using the host) so that scenarios you mention work. If you were to host ASP.NET Core in a WinForms or WPF application, you would end up calling StartAsync from the UI thread and that would do the right thing and use ConfigureAwait(false) internally. Request processing on the other hand is dispatching to the thread pool so unless some other component explicitly set a SynchronizationContext, requests are running on thread pool threads.
>
> Blazor on the other hand does have a SynchronizationContext when running inside of a Blazor component.
So I bring this up as a case of how supporting multiple platforms and runtime scenarios does indeed add some layer of complexity.This is a good example of C# light-touch on language design. Async/await creates a state machine out of your methods but that's all it does. The language itself delegates entirely to platform/framework for the implementation. You can swap in your own implementation (just as it possible with this union feature)
> So I bring this up as a case of how supporting multiple platforms and runtime scenarios does indeed add some layer of complexity.
I agree that's true. A language that doesn't support multiple platforms and runtime scenarios can, indeed, be simpler. However that doesn't make the task simpler -- now you just have to use different languages entirely with potentially different semantics. If your task is just one platform and one runtime scenario, the mental cost here is still low. You don't actually need to know those other details.
Your original quote, verbatim:
> Eg compare to strongly-typed query generators
"strongly-typed query generators" not "strongly-typed command generators" nor "strongly-typed code generators".EF is precisely a code to structured query language (SQL) query generator and not a query to code generator.