Only vague notions, nothing ready to formally propose. Optional has hardcoded support for being a supertype of its `Some` payload; it might be worth surfacing that as a language feature other enums can also take advantage of:
enum Optional<Wrapped> {
// Strawman: 'sub case' declares a case whose type becomes a subtype of the enum
sub case Some(Wrapped)
case None
}
enum Result<Success, Error: ErrorType> {
sub case OK(Success)
case Error(Error)
}
There would need to be constraints so that two 'sub cases' are never able to have overlapping payload types—otherwise with something like Either<Int, Int>, it'd be ambiguous which side of Either Int promotes to. OTOH, optional subtyping also causes some issues (1 < nil works being one of the more prominent ones), so we may not want to dig the subtyping hole deeper either…like I said, only vague notions.
-Joe
···
On Dec 3, 2015, at 3:32 PM, Anandabits <matthew@anandabits.com> wrote:
There are cases when the library isn't designed to support new conformances for the protocol, but the protocol is public because other public APIs are expressed in terms of it.
We have a case for it in the standard library, 'protocol AnyCollectionType'. Foundation also has a use case -- property list types.
I have had cases for this as well. Joe Groff's suggestion of adding more convenient syntax for sum types as an alternative may be an acceptable alternative for the cases I have seen, although I would need to have a better idea of what that might look like. Joe, have you written a proposal for this?