bdriscoll:
For parody with opaque return types func foo<T>() could be sugar for func foo<any T>() . In other words, I would like to use any as a keyword, but for an entirely different purpose than discussed in this thread. As an alternative to what any was used for in the above discussion I would propose dyn (like Rust) or dynamic if Swift prefers whole words too abbreviations. If we wanted a symmetric syntax to func foo() -> some P it would turn into func foo(_ t: any T) and not func foo(_ t: some T) as discussed above.
I'm not sure I'm understanding your discussion about Haskell correctly, but I agree with this from another point. My concern is about use of some for generics, and previously held discussion here.
I read these discussions, and I now have a concern about it.
In theory, we can think about what happens if reverse generics was applied in argument type considering the next example.
// Reverse generics in result
func callee<opaque T: FixedWidthInteger>() -> T { /* ... */ }
// Reverse generics in argument
// The actual type of `T` is `Int64`, but from the caller it seems to be opaque
func callee<opaque T: FixedWidthInteger = Int64>(_ value: T) { /* ... */ }
<opaque T: FixedWidthInteger…
I think it makes much more sense to use any for generics , some for reverse generics , and use other keyword for existential types.