[swift-evolution] Proposal: Sealed protocols

[Joe Groff]

> On Dec 3, 2015, at 3:32 PM, Anandabits <matthew at 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?

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