Joe_Groff
March 5, 2022, 12:51am
2
lhunath:
We also notice that if users find value in using type erasure to architect their applications, creating custom type erasure types is a huge hassle involving creating duplicating type definitions and concrete type wrappers. A hassle which might be avoided if we could simply adopt the any P mechanism consistently for the purposes of type erasure, foregoing the need for AnyP wrapper types.
Is there an analysis that I can find about why Swift has gone the route of encouraging type erasure through wrapper types rather than elevating the capabilities of its protocol existentials to first-class types? How come protocol existentials do not behave the same way as concrete type wrappers do? (eg. relating issues such as access to static members)
We don't intentionally encourage manual type erasure; it's been a matter of development priorities that we haven't had time to flesh out the implementation of built-in existential types, and so manual type erasure has been necessary to overcome those limitations. However, we are now actively working on breaking down some of these limitations:
Hi all,
I've been looking into generics ergonomics, and one of the problems that keeps coming up is that going from concrete types or generics into existentials is a bit of a one-way street: you can create an any P from a value of any type that conforms to P, but once you have that existential value of type any P it's hard to get back to using generics. Here's a quick example:
protocol P {
associatedtype A
func getA() -> A
}
func takeP<T: P>(_ value: T) { }
func test(p: any P) {
t…
Constraints on opaque and existential types are currently limited to protocol and protocol composition requirements on the underlying type. More advanced requirements, such as constraining an associated type, are currently not supported in the language. [Pitch 2] Light-weight same-type requirement syntax proposes to add a limited form of same-type requirement on "primary" associated types, but this feature is not a replacement for a more general syntax.
This post outlines a few ideas for expres…
You are right that in the fullness of time, built-in existential types ought to be sufficient and manual type erasure should become unnecessary.
14 Likes