Reverse generics for argument type?

[sighoya]

@xAlien95

Who decides which types == (lhs: some Equatable, rhs: some Equatable) -> Bool can accept in argument position? It's the function == , not the caller:

@xAlien95

The declaration of == constrains both lhs and rhs to have the same type, which is the type Self of the instance (in this case the instance is p ).

You refer to the example with two Self parameters, the only constraint the callee (i.e. ==) adds to the context is that both parameters must be the same which is currently only unique for the same variable or different aliases to the same variable.

But == doesn't specify what Self has to be for a type, that is specified by the caller, in our case it was specified by another callee with name Private which was executed in the caller.

@Dante-Broggi

@sighoya

I disagree. But maybe the term existential is redefined in Swift context, but this would lead to more confusion for users coming from other languages already knowing existentials.

So, I believe that this side discussion is fundamentally about a disagreement over the definition of "existential".

IIUC, your definition of "existential" is similar to:

a value of an existential of protocol P is a value v for which there exists a type T , such that v is of type T and T conforms to P .

Under this definition the value boxed in any P and both possible extensions of some P are existentials.

However, IIUC the definition of "existential" in general use in the Swift community is similar to:

a value of an existential of protocol P is a value b which contains a value v for which there exists a type T , such that v is of type T and T conforms to P , and b contains proofs of those statements about v .

Under this definition, any P , but not the value boxed in it, is an existential, but some P is not, because the proofs for some P are not stored in the value, but in the context.

First I wouldn't call a value an existential, this is more kinded to a variable.
Second, we could also store the proofs of some P inside the value of some P and unwrap the existential behind, but why we should do so if there is the option to optimize the boxing of some P out by simply replacing the box with the underlying type.

Yes, I see your point.
The Swift definition of existentials is more related to implementation details, my is more of abstract nature. So you are mostly correct with your conclusion.