These are very helpful! I actually have a fourth potential interpretation, which is (I think) more useful in practice and IIRC was part of the motivation for SE-0328 prohibiting the use of some in consuming positions. The observation (based on the SE-0328 discussion) is that opaque types in consuming positions are hard to use because the wrong code (caller vs. callee) gets to choose the parameter. So, this approach "flips" the position of the <T> across the ->. It looks like this:
func f0() -> some P
func f0() -> <T: P> T
func f1(value: some P) -> Void
func f1<T: P>(value: T) -> Void
func f2(closure: (some P) -> (some P)) -> (some P) -> (some P)
func f2<B: P, C: P>(closure: (A) -> B)) -> <A: P, D: P> (C) -> D
This way, the caller gets to choose the values it will provide (B, returned by closure; and C, passed to the function returned from f2), and the callee gets to choose the values it will provide (A, when fn2 calls closure; and D, the result from calling the function returned from f2).
I do not think SE-0341 should go this far. Rather, I suggest that we prohibit opaque types in consuming positions, mirroring the restrictions put in place as part of the acceptance of SE-0328. If we want to lift the restriction later, we would do so in one proposal that applies to opaque parameter and result types consistently. I have put up a pull request that amends SE-0341 in this manner, with this "flip" approach in Future Directions.
@xwu 's argument would be for a greater restriction, which would prevent opaque types in effectively any function type, to prevent a future ambiguity (or oddity) if Swift gains first-class generic functions. It would apply equally to this proposal and SE-0328. My inclination is to disagree for a few reasons:
- I don't think Swift is all that likely to gain first-class generic functions,
- I think that having opaque types create generic parameters in the innermost declaration (as proposal) vs. the innermost function type(@xwu's suggestion) is more likely what one would want, and
- Even if both of those are wrong, it's only syntactic sugar and one can write out the full form.
That said, I lost a similar argument years ago about suffix ... and now it's causing the trouble I predicted with variadic generics, so I sympathize 
.
Doug