[Pitch] Opaque parameter types

[hborla (Holly Borla)]

@ksluder

I can’t recall whether func f<T: P>(any T) is legal.

No, this is not legal. The operand to any must also be a protocol or protocol composition. From SE-0335:

Explicit any can only be applied to protocols and protocol compositions, or metatypes thereof; any cannot be applied to nominal types, structural types, type parameters, and protocol metatypes

[ensan-hcl (ensan)]

Wow. Actually, I didn't expect that. How does that behave inside function? I feel it is a quite strange exception that (some P) -> () is only allowed in argument position of function.

func foo(value: some Any) {
    let a = value             // possible
    let b: some Any = value   // possible
    let c: any Any = value    // possible
}

func foo(closure: (some Any) -> ()) {
    let a = closure                     // possible
    let b: (some Any) -> () = closure   // impossible due to the restriction?
    let c: (any Any) -> () = closure    // possible
}

[fclout]

A reason that some is interesting in return type positions is that the type is decided by the callee instead of the caller. Using View for lack of another concrete example, wouldn't it be nice if this worked?

func passView(action: (some View) -> Void) {
    let view = VStack { HStack { ... } ... }
    action(view)
}

This is not something that you can do today with the regular generic syntax. This would require the closure to be generic and accept any kind of View. I understand that generic closures don't exist and may well never exist, but to me it would be more self-consistent to just not allow some in closure parameters.

[Douglas_Gregor]

@ksluder

@Douglas_Gregor

the Swift type system doesn't have first-class generic functions, i.e., you cannot have a value of type <T>(T) -> Void : context must provide a specific binding for T .

Might this feature be added in the future? If so, is this proposal forward-compatible with it? (I suspect it is, but it may not be able to express all types that a syntax with explicit type parameters could express).

We could add first-class generic function values in the future. Opaque parameter types would be no better or worse than their equivalent generic functions with respect to forward compatibility, and I'm fairly certain we could handle it: we'd bind the generic arguments when we can infer them, and leave the result generic when we cannot.

@ensan-hcl

func foo(closure: (some Any) -> ()) {
    let a = closure                     // possible
    let b: (some Any) -> () = closure   // impossible due to the restriction?
    let c: (any Any) -> () = closure    // possible
}

b is ill-formed. The only thing it could really mean would be

let b2: (_) -> () = closure 

I don't know that we need to allow the redundant spelling here.

Note that c is ill-formed, because the closure can't take any Any, it can only take the specific type of the closure (i.e., the synthesized generic parameter).

Doug

[ensan-hcl (ensan)]

OK, I'm sorry in that c is ill-formed. But that's not my point. I'm asking that, why a type which cannot appear in let statements can appear in function parameter position. Other types containing some do appear in both parameter position and let statements. The behavior of (some P) -> () is quite strange.

It contains another problem, please read my comment in the proposal review thread Maybe we should argue in the review thread, in order not to scatter the discussion.

@ensan-hcl

SE-0328 rejected adding some P in 'consuming' position of closure, because at that point we were afraid that adding such a closure contradicts with this SE-0341 == 'generalized some syntax'. But this SE-0341 introduces the some P in 'consuming' position of closure in the parameter position of function. At least, please explain, why? This problem cannot be resolved if you prohibit the use of (some P) -> () in parameter position. The proposed behavior of it is quite natural considering it as a sugar of generics. Prohibiting that introduces a new strange exception into Swift.