SE-0328: Structural opaque result types

Evolution Proposal Reviews
8

All great. :smiley_cat:

But as "more APIs [are] expressed using opaque result types", you'll find more cases where being explicit is necessary. I'd rather this not be undertaken without as some support, so that the new APIs can match the ergonomics of their existential variants.

E.g. given:

protocol P1 { }
protocol P2 { }

struct S: P1, P2 { }

Explicitness with existentials is supported in-line.

func Æ’(_: P1) { }
func Æ’(_: P2) { }

Æ’(S() as P1)

But with generics, it is not.

func Æ’<T: P1>(_: T) { }
func Æ’<T: P2>(_: T) { }

let p1: some P1 = S()
Æ’(p1)

So, please add that capability in:

Æ’(S() as some P1)

func Æ’() -> (some P1)? { S() }
func Æ’() -> (some P2)? { S() }

Æ’() as (some P2)?

The last example requires overloading based on opaque return type to be supported. Hopefully that's coming along with this proposal too?

func Æ’() -> some P1 { S() }
func Æ’() -> some P2 { S() } // Invalid redeclaration of 'Æ’()'
1 Like