Opaque result types

[anthonylatsis]

@Douglas_Gregor

I've been thinking about this for a bit, and the second bullet is really what gets to me. That syntax I conjured up to describe conditional conformance is rather awful. It's completely non obvious and quite verbose. @dabrahams improved on it a bit, but it's verbose by necessity.

A couple of ideas on this matter.

//#1 Tackling the syntax

// For in-place definition, implies that the opaque type can be named, and a 'when' keyword. 
-> opaque T where T: BidirectionalCollection,
                  T: RandomAccessCollection when Self: RandomAccessCollection,
                  T: MutableCollection when Self: MutableCollection,
                  T.Element == Element

// Through type aliases
typealias T = opaque BidirectionalCollection where 
                     T: RandomAccessCollection when Self: RandomAccessCollection,
                     T: MutableCollection when Self: MutableCollection,
                     T.Element == Element

// #2 Tackling verboseness

// If the compiler could infer a single return type and then auto-generate the necessary
// constraints for T, it's opaque version (the 'existential skeleton'),
// that would be fantastic. T.Element == Element is an example of an additional external constraint.
-> opaque T where T.Element == Element

@Douglas_Gregor

I think the right course forward for this proposal is to introduce opaque type aliases, which give a name to the opaque type so that it can be reused/tweaked. That provides a natural way to describe the conditional conformance, so we can eliminate the awful conditional-conformance-in-the-result-type syntax from the proposal.

What we really want is to be able to express merely the existence of a conditional conformance, right? I wouldn't say the current syntax for declaring conditional conformances is suitable for that, especially if we want to express a conditional conformance in a signature.