[Discussion] enable `some` in closure parameter position

[ensan-hcl (ensan)]

I almost agree with your argument of practicality. It is impossible for me to consider practical usages of such functions. But practicality doesn't support exclusion of a feature. The function in the following code doesn't have practicality, but there is no reason to ban it.

// there is no way to call the closure
func foo<T>(closure: (T) -> ())

If there is no other way rather than using some for generics, then we have enough reason to ban (some P) -> (). However, since there are alternative ways to achieve shorthands for generics, banning (some P) -> () doesn't seem to have sufficient reason to introduce such an artificial limitation.

---

@xwu

because the alternative you propose is opposite to how subclassing [edit: and protocol requirement fulfillment] works (inconsistency argument)

[Discussion] Easing the learning curve for introducing generic parameters

—Not to beat a dead horse, but I wonder if I’m wrong in this: If the pitched syntax generalizing some to generic constraints is adopted, then who chooses the conforming type here: protocol P { } func f(_: some P) -> some P { } …exactly parallels who chooses the subtype here: class C { } func f(_: C) -> C { }

Are you mentioning this? About it, I think this is just the difference in the way of considering.

some P doesn't work how subclassing works even now.

// subclassing (Dog: Animal)
var da: (Dog) -> Animal = { $0 }
var dd: (Dog) -> Dog = { $0 }
da = dd

// some syntax (T: P)
var ts: (T) -> some P = { $0 }
var tt: (T) -> T = { $0 }
ts = tt // error, because some P is not always T

In the code below, the behavioral type of argument and result of foo is the same, but in bar it's not. Even in generalized some syntax there is a behavioral inconsistency.

// the two 'C' is 'the same type' at least being C
func foo(value: C) -> C { value }
var c: C = C0()
c = foo(value: c)

// generalized `some` syntax
// the two 'some P' is not the same type
func bar(value: some P) -> some P { value }
var p: some P = P0()
p = bar(value: p)  // error

I'm not sure if it is valid to assume behavioral consistency between the subclassing/any types and some/??? types. In many aspects, some syntax behaves differently to how subclassing works. I cannot understand why consistency in subclassing and some/??? syntax is required.

From the beginning, I think (C) -> C is just taking C and returning C, not caller/callee-decided subclass of C. The callee decided to just take C and return C. Likewise, (any P) -> (any P) is just taking any P and returning any P. The callee can also use some to tell 'callee-decided opaque type' and ??? to request 'caller-decided generic type'. Am I missing something?