Existential subtyping as generic constraint

[anandabits (Matthew Johnson)]

@Nickolas_Pohilets

Compiler already supports that, and it simply MyClass .

Exactly. If you want to apply the notion of existentials to types, it would be applied to generic types (i.e. type constructors) and we would have things along the lines of any Array. This same notion would apply to classes.

@DevAndArtist

We don't have the notion of 'exactly that type' in Swift.

Do you know of any OO language which has such a notion? Do you know of any use cases for it? It doesn't sound like something that would be useful to me.

@DevAndArtist

To get back on track I think what we really want to be able to express in this proposal is the difference between an 'existential' and a 'protocol' as a constraint.

protocol Proto {}
func f1<T: Proto>(_ t: T)     // T that conforms to protocol `Proto`
func f2<T: any Proto>(_ t: T) // T that is a subtype of `any Proto` existential

This is why I said upthread that we wouldn't be able to use existential subtype constraints without introducing the any syntax. I think it's rare that an existential subtype constraint would be useful anyway so I don't think it matters too much that we are currently unable to spell it.

@DevAndArtist

(I think for classes the ship has sailed and it would be a huge breaking change to differ Object vs. any Object , if we really wanted to.)

What do you mean here? IMO, the any AnyObject syntax is clunky and confusing to the point that it might be enough to warrant deprecating AnyObject and replacing it with Object, which is already considered a bit of a wart.

@Nickolas_Pohilets

Thinking about Array , I've just realised that there are two kinds of existential here:

• any Array - abstracts away generic parameter(s).
• any Array<String?> - value subtyping

Why would we want an existential in the latter case? It seems to me that importing language support for variance would be the more productive path there.