Structural opaque result types

[ensan-hcl (ensan)]

It's great!

But I doubt this point.

@bdriscoll

If the result type of a function, the type of a variable, or the result type of a subscript is a function type, that function type can contain arbitrary structural opaque result types. For example, func f() -> () -> some P and func g() -> (some P) -> () .

Note that the closure value produced by calling g in the above example is itself uncallable. It has type (some P) -> () , meaning it takes an opaque result type as an argument. That argument has some concrete type, T , determined by the body of the closure. Obviously the client cannot call the closure with a value of some other type, U . However, the client also cannot call the closure with a value of type T . If they were able to, then they would be depending at the source level on the concrete type to remain fixed, which is one of the things opaque result types are designed to prevent.

[Edit]
I've misread. This is only an example which closure with opaque result type argument can be called.

IIUC, your argument is that, there is no way to call g, and therefore should be explicitly disallowed. But it's not true. I previously posted about 'reverse generic argument types'. Consider following closure:

var closure: (some Numeric) -> () = { (value: Double) in print(value) }

some Numeric is actually Double, but it doesn't matter. We have information about some Numeric: it conforms to ExpressibleByIntegerLiteral and it has static property zero. Therefore, even though we cannot call this closure with Double, we can still use this closure like this:

closure(42)       // 42
closure(21)       // 21
closure(.zero)    // 0

Actually similar behavior has been in the current Swift already. You can try how it works:

protocol Printer {
    func print(value: Self)
}
extension Double: Printer {
    func print(value: Double) { Swift.print(value) }
}
let d: some (Numeric & Printer) = 42.0
let closure = d.print
// you can still call this closure!
closure(42.0)    // error (since type is opaque)
closure(42)      // OK (from ExpressibleByIntegerLiteral)
closure(.zero)   // OK (from AdditiveArithmetic)

Like this, having g doesn't cause any problems. You can still call the closure, and use it. There is no reason to explicitly disallow it.