Improving the UI of Swift Generics
This document tries to provide a foundation for conversations about refining the generics model, not really changing the framework established by the Generics Manifesto, but considering some of its weaknesses, and how we might make it more approachable and easier to use:
- One of the biggest missing pieces from the original manifesto is generalized existentials. These have been hailed as a panacea for a wide range of problems, but as we’ve explored the idea, we’ve found that there are many use cases that existentials would never be able to address.
- In particular, although existentials would allow functions to hide their concrete return types behind protocols as implementation details, they would not always be the most desirable tool for this job. We have a gap in the generics model in allowing functions to abstract their concrete return types while still maintaining the underlying type’s identity in client code, and we’ll look at how that gap can be filled.
- We’ll also look at our existing notation for generics and existentials. Swift follows in the tradition of similar languages like C++, Java, and C# in its generics notation, using explicit type variable declarations in angle brackets, but this notation can be verbose and awkward. We could look at what C++20 is doing with abbreviated templates, and Rust with its
impl Traitfeature, for ways to make writing generic functions more concise and fluent. Also, protocols currently do double-duty as the spelling for existential types, but this relationship has been a common source of confusion.
Update (2019-04-15): Tim Ekl (Hacker News):
To that end, this post aims to walk through some of the proposals from Joe’s document, explaining the syntax and offering examples of how the changes to generics might look in practice. We’ll pick up a couple technical terms in a practical setting, and wrap up with some details about the open Swift Evolution proposal(s) being considered.
3 Comments RSS · Twitter
In a few years, swift will have all the complexity of C++, but few of the benefits. It’s already such a complex language with so much oportunity for doing look-at-how-smart-I-am stuff and suffering from the perfect is the enemy of good syndrome: just look at the endless changes to already complex collection hierarchy.
For all its flaws, Objective-C is still a remarkable pragmatic language. I wish Apple actually gave us the Objective-C without the C they promised Instead, all we got is a new C++ :(
@A - I am glad I am not the only one thinking Swift is increasingly like modern C++. Yes Objective-C has lots of quirks, but it is relatively simple. Swift? I don't even know where to begin.
Frankly I'd rather the Swift team had thought about generics & protocols with associated types a bit more up front and come up with a more cohesive approach. The fact that so many people resort to type-erasure in a language that is so adamant about static typing is surely a sign that's something's not working properly. Personally, I'm using fully abstract base classes (which admittedly are something else Swift doesn't support) to work around the Swift compiler's refusal to reason about protocols with associated types because it feels more honest than type-erasure.
