The way I would like to see the evolution of any/some is that after MVP:s like the latest SE-0244: Opaque Result Types (reopened) - #22 by Moximillian, the named types would be introduced (at some point): some Collection C, maybe any Protocol A, to handle all the complexity with constraints and others, which comes with no requirement for new syntax for setting up constraint rules etc.This gets us full functionality.
Once that is in use and people see actual code, then introduce some well-chosen shorthands for anonymous types, where they make sense. After all, at that point it's mostly just eye-candy, and we can have a little bit patience for one's favorite sugar, right?
EDIT: hmm, if named some types would be used e.g. in stdlib/Foundation, would those names be visible to users of library? If that’s a problem then maybe initial implementation of named some types could be converted to anonymous by the compiler behind the scenes so that names are not visible to outside of module... Ultimately, since there’s been discussion about figuring ways to refer to anonymous types too, I’m not sure such conversion would be worth it though. You’re not really hiding anything, just making it more difficult to use it?
We do have precedent with regular generics func foo<T: P>() of having always to name the type. And we have survived quite well without anonymous types there. While some is bit different when used as reverse generic (return type), I think naming is still right place to start. If I understand correctly, the current existential syntax func foo(item: Protocol) is effectively anonymous type equivalent and people are struggling with that concept and inability to refer to the exact named thing.
In terms of ease of use, here’s a bit exaggarated example:
Current
func foo(item: Protocol)
— Error: ”protocol Protocol does not conform to protocol Protocol”
with named any
func foo(item: any Protocol I)
— Error: ”existential I does not conform to protocol Protocol”