SE-0335: Introduce existential `any`

[Nickolas_Pohilets (Nickolas Pokhylets)]

@hborla

• We could keep around Any and AnyObject as type aliases to any Value and any Object , respectively, to minimize the code churn. This could also provide a nicer solution to needing to write any Swift.Object when the project has its own Object , but it still requires Swift.Object when writing a layout constraint in that case.

One observation is that Any is useless as a generic constraint unless you want to write an unconstrained opaque type some Any .

Till some point I was even thinking that Any is an existential, not a protocol.

We could avoid having Value protocol altogether, and keep Any as a existential only. For now as a compiler built-in, and with generalized existentials make it a typealias for any<T> T.

It not only removes a redundant entity, but also eliminates self-conformance (any Value): Value.

But then, as you mentioned, until we have generalized opaque types we cannot express some<T> T. Not sure if that’s a big loss though. I cannot think of any useful operations on values of unconstrained opaque type, which do not involve wrapping it into Any (existential). And if you end up wrapping it into an existential, you can just return an existential in the first place.

And also semantics of Any.Type changes into singletone metatype, which is not what is needed in the majority of cases. So additionally there would need to be a builtin/typealias AnyType = any<T> T.Type. Which sounds ok to me - Any, AnyType, AnyObject look pretty consistent together.