You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It strikes me that we could perhaps eliminate NoneType and have Maybe<T> even without all of #33. (I was inspired by @raiph in thinking in this direction.)
The premise is this:
None and NoneType are gone.
Whenever you want to allow for a None-like value, you give something the type Maybe<Expr> or similar. On the Perl 6 level.
But without any type annotations and type inference switched on, these switch statements are mostly just syntax; they're a way to dig into a Maybe, but they don't come with any strictures. (No totality checking; no checking the cases against the surrounding type.)
I should add that this would be an experiment, to see if we like it better than the current None status quo. There is promise in the idea; it would for example address the concerns raised in #148, too.
The text was updated successfully, but these errors were encountered:
I liked pampy, which provides a pretty neat library-only way to pattern match. We could try porting it to 007 and see how it looks; it might be a sensible step on the way to doing pattern matching with syntax.
I'm going to close this one; I find I don't believe strongly in getting rid of none these days. (Also, TypeScript sort of shows that it's not super-necessary either.)
It strikes me that we could perhaps eliminate
NoneType
and haveMaybe<T>
even without all of #33. (I was inspired by @raiph in thinking in this direction.)The premise is this:
None
andNoneType
are gone.None
-like value, you give something the typeMaybe<Expr>
or similar. On the Perl 6 level.Maybe
, but they don't come with any strictures. (No totality checking; no checking the cases against the surrounding type.)I should add that this would be an experiment, to see if we like it better than the current
None
status quo. There is promise in the idea; it would for example address the concerns raised in #148, too.The text was updated successfully, but these errors were encountered: