27 lines
1.8 KiB
Markdown
27 lines
1.8 KiB
Markdown
# C# Language Design Notes for Jan 10, 2017
|
|
|
|
## Agenda
|
|
|
|
- Discriminated unions via "closed" types
|
|
|
|
# Discriminated unions via "closed" types
|
|
|
|
There's a [proposal](https://github.com/dotnet/roslyn/issues/8729) to allow adding `closed` to an abstract type. This prevents inheriting from any other assembly, meaning that there would be a known set of derived types, all in the same assembly as the closed abstract type. This is somewhat similar to Scala's case classes.
|
|
|
|
At the metadata level, this could possibly be implemented by generating an internal abstract member. In fact that member could make itself useful as a property returning a tag, so we can do efficient tag-based switching.
|
|
|
|
A nice aspect is that `closed` can be added to existing hierarchies, adding a notion of completeness and protecting from "unauthorized" inheritance.
|
|
|
|
Adding this to existing code may lead to completeness warnings in consuming code.
|
|
|
|
In a lot of places where you switch, you don't even *want* completeness. It's almost like it's something you have to ask for at the switch site. Special syntax?
|
|
|
|
"Catch all" is a problem. Often I want to have a catch all *even* as I want to be told if there's a new case. We *could* say that if there's a closed type, then you need to be complete in a switch. Which you can be with a `default`, but then you won't know if there's a new case: it's up to you.
|
|
|
|
Enums: We could allow `closed` on those, and then eliminate the explicit conversion to it, as well as arithmetic. Switching could generate a default that throws, in case someone monkeyed an illegal value in there.
|
|
|
|
A closed enum wouldn't get much value out of being an enum, since we don't want operators to work on them. We could consider making them not be enums from the runtime perspective.
|
|
|
|
## Conclusion
|
|
|
|
An interesting approach to discriminated unions that might be a better fit with the spirit of C#.
|