I'm neutral on adding syntax sugar for generics, but I opposed to this proposal in the use of some.
First, as some of other people reffered, the use of some in parameter position is confusing. It depends on how to learn, but if learners will see some in parameter position at first, and find the notion of generics. After that, the learners will consider that func foo() -> some P is also a generic function, due to the use of some.
In the future, full-power reverse generics syntax (often reffered as func foo() -> <T> T or func<^T> foo() -> T) can be introduced. Swift then has three different features at that point; 1: generics, 2: some, 3: reverse generics. Among these three features, some only seems a chimera of generics and reverse generics. On this point I cannot believe using some is semantically natural.
Second, the proposed some syntax introduces contradiction. In the pitch thread, @Douglas_Gregor explained that (some P) -> () is allowed in parameter position (link), though SE-0328 prohibits introducing it with let statement. As far as I read the proposal, I couldn't find any change on this point. Based on the proposal, (some P) -> () in parameter position behaves as the following.
// proposed syntax
func foo(f: (some Numeric) -> ()) {
f(42)
}
// equal to current Swift
func foo<T: Numeric>(f: (T) -> ()) {
f(42)
}
I agree that this is natural. However, considering the next code, it seems quite strange because function f and closure f both have type (some Numeric) -> () but behave totally different.
// proposed syntax
func foo(f: (some Numeric) -> ()) {
f(42) // f is not a generic function
f(42 as Int) // error
f(42 as Float) // error
}
// proposed syntax
func f(_ value: some Numeric) {}
f(42) // ok, f is a generic function here!
f(42 as Int) // ok
f(42 as Float) // ok
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.
After all, I think these problems came from the trial to distinguish some as both generics and 'reverse generics' based on the position. I strongly suggest that we should use other keyword for the proposed feature.