- What is your evaluation of the proposal?
Strong +1, it feels like a natural extension of the language from my perspective.
I appreciate all the thought put into the criticisms of this proposal, particularly:
Sequence<.Element == Int>alternative
- the "generic protocols" discussion
I feel the authors have done an excellent job explaining their choices in these areas. I find the resulting proposal very compelling.
- Is the problem being addressed significant enough to warrant a change to Swift?
Yes, it has the potential to simplify a lot of declarations, especially in functions. I found the "equivalent to" examples in the proposal particularly compelling.
Having written my fair share of generic framework code for a large enterprise app, I can see myself preferring this to the existing where clauses.
- Does this proposal fit well with the feel and direction of Swift?
Yes, I think so. But this is very subjective.
At first blush, it felt like a departure from Swift as I know it. I'm very familiar with using generics and reading their signatures, so at first this was admittedly difficult for me to interpret.
However, reading the proposal with fresh eyes, this feels like a very natural way to introduce "simple generic constraints" to beginners. I found the use cases very compelling.
That said, as evidenced by some of the reactions in the pitch thread, experienced programmers coming from languages like C++ and Rust might find the generics-like syntax more confusing. They seem to expect more sophisticated features like "generic protocols".
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I don't have experience with this feature or the "generic protocols" feature from other languages. As a result, I found some of the pitch discussion difficult to follow.
I did find this rationale from the proposal compelling.
We believe that constraining primary associated types is a more generally useful feature than generic protocols, and using angle-bracket syntax for constraining primary associated types gives users what they generally expect, with the clear analogy between
Associated types (and this syntactic sugar for them) are one of the most compelling reasons to use protocols in Swift. The proposal opens up new possibilities for API design in this space.
I trust the proposal authors when they say the "generic protocols" feature could be implemented using alternative syntax.
I would prefer using this syntax as the proposal describes, not for "generic protocols"
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've followed the original pitch thread, read the original pitch and this updated proposal. I've thought about how I might use this in my own framework code.