SE-0309: Unlock existential types for all protocols

[ensan-hcl (ensan)]

I totally agree with your explanation.

@Moximillian

But you could in the future have also anonymous generics with some

func foo(collection: some [P]) 

For example, if you pass [1,2,3] to the function foo, then only Ints can be stored in that collection, and no changes can be done to that inside the function or at runtime.

so the word "some" here is meant to signify "a single concrete type from a set of possible types"

But I’m worried about this point. Is it agreed direction? As far as I know using some for 'anonymous generics' is still not agreed direction now. If this syntax were to reject, the contrast of any and some collapsed. Then it would become more confusing than ever. If this direction is already formally agreed and there is no possibility to be rejected, I also think using any for existential type is great.

I'm now considering about reverse generics for argument. I think this would potentially threaten the direction to use some for normal generics. Because it would be off-topic, I opened a new topic. I'd happy if you check it.

Reverse generics for argument type?

https://forums.swift.org/t/reverse-generics-and-opaque-result-types/21608 https://forums.swift.org/t/improving-the-ui-of-generics/22814 https://forums.swift.org/t/se-0309-unlock-existential-types-for-all-protocols/47515 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 { /* ... */ } …

I hope my concerns are wrong. In that case, I also agree with the use of any P for existential types.