SE-0309: Unlock existential types for all protocols

[ensan-hcl (ensan)]

I do agree we need to disambiguous the meaning of existential type and protocol constraints, but I doubt the 'any' is a good choice. As far as I read the discussion above, there are no clear contrasting relationship between existential types and opaque types that any/some suggests.

@1oo7

func process<T: Processable>(_ item: T) -> any Usable 

That's more ambiguous, not less, because now it makes sound like Usable is a constraint on any type that gets returned by the function, just like View is a constraint on some View that gets returned by a SwiftUI body. However this function won't return just "any" concrete type that conforms to Usable , it will always return the same exact type: Usable (the existential).

I really agree this concern. For me it feels exactly any concrete type that conforms to Usable. It also seems similar to generic result types.

Also, if I understand correctly, currently, it is not the clearly-agreed direction to use some for generics discussed here. If we don't take the direction, there is possibility to use any for other purpose, for example, some for 'reverse generics' and any for 'generics'.

I'm +1 on unlocking existential types for all protocols, but -1 on making it stable direction to use any P for existential types. At least, it should be decided after the whole direction of generics UI is decided. For what the any should be used, should be more carefully considered.