Open plajjan opened 2 years ago
Could not agree more!
But the exhaustive idea must also be coupled to some ability to close a class's extension hierarchy. Say that we have a class MyType
with two subclasses MyVariantA
and MyVariantB
, and assume variable x : MyType
. We can then look at a match statement
match x:
case MyVariantA: ...
case MyVariantB: ...
and conclude it's exhaustive only if we can conclude that no-one is ever going to define another subclass of MyType
! That is, we must be able to prohibit a future definition of class MyVariantC (MyType)
.
How can we achieve that? Something to ponder!
Not sure that it "must" be coupled... like, if you turned on exhaustive-patterns on the above, it would essentially force you to write an case _: ...
I guess!? So it would work, just perhaps be more cumbersome, but then again, just turn off exhaustive-patterns?
I'm thinking of pattern matching for low level stuff in libraries, like writing an XML parser or parsing some bits from the network where we'll have more of primitive types like bytes, str or int. I find it likely that I will always need a final wildcard since I simply do not know what someone will send to me. I think having an exhaustive-patterns flag would lead to higher quality in such modules since we must explicitly handle errors.
Hell, I'd even be fine with only supporting exhaustive pattern matching to begin with and have non-exhaustive added as a later thing.
Half side note; We must reduce the size of deliverables so we can iterate and move forward. No big bang changes that fixes everything to perfection...
match
is really the way it ought to work. We should try to add support for this sooner rather than later, since it would be really nice to write large parts of the standard library using match patterns.I'd particularly like to have some form of language strictness mode where I can say that pattern matches must be exhaustive (this could really go for any sort of condition, but is somehow more natural I think for pattern matching).