2.6 KiB
C# Language Design Notes for May 23, 2018
Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!
Working with data
Collections of data with heterogeneous types.
It's not objects, but decoupled from operations.
- tuples
- anonymous types
- classes
All have a mutability issue, just different ways.
Modeling enumerated types is complex and doesn't provide exhaustiveness.
Also, you cannot efficiently switch over different types. You do tricks like visitors, abstract kind properties, etc. Performance, correctness and succinctness are all in conflict. Type patterns help, because they look good, but they are still not as efficient or as safe as they could be.
Technically speaking, mutability and value equality are a dangerous combo on classes. If the object mutates, its equality and hashcode change, meaning you could lose track of them in dictionaries, etc.
On the other hand, C# is mutable by default: should we bend over backwards to not support this combo?
Object initializers aren't strictly necessary, but they jive well with with expressions, give a less positional view.
Object initializers are really popular today, in that they are used a lot. But it's unclear whether they are because the declaration site doesn't provide constructors, and instead do the "easy" thing of just offering auto-properties.
Withers: we keep talking about them for readonly data, but they might very well be useful on mutable data as well.
The "data classes" proposal puts weight on not being positional. It could even reorder members alphabetically in generated positional constructs such as constructors.
Separately, there is an idea of "named tuples". These are what have previously been proposed as "records". These are an evolution story for tuples.
This may be an overload of concepts. It may be that we can view them as aspects of the same feature; one may be an evolution of the other.
Discriminated syntax: Enum classes. Starts very simple, probably has ways of letting you grow up. That gets messy though, with the nesting, but we could use partial to separate things.
Kind fields must necessarily be unspeakable, and discoverable only by the compiler. Otherwise they can't be efficient.
Records and data classes are extensions of existing constructs. Enum classes are more of a new concept.
We kind of agree on the simple cases. It's how they grow up and fit into the existing world that's fraught with questions.
Interestingly, you sometimes want your "enums" not to be exhaustive. This is the case when you expect it to evolve with more cases.