- What is your evaluation of the proposal?
Overall +1, but deferring handling Optionals will impede my ability to fully make use of this feature.
For better or for worse, Optionals have a special place in the type system, and there's this weird boundary with them:
- There's no
IsOptionaltype of protocol (in the language or standard library) unless I write my own to add it to the opaque type signature - There's no way of returning an optional in a reverse generic function - when I might want to. This would be an "arbitrary" restriction from my standpoint.
- Is the problem being addressed significant enough to warrant a change to Swift?
Yes, definitely. Part of my development time is spent understanding the huge landscape of names and trying to comprehend how they piece together and what I should or should not be using directly in documentation (which may not be the greatest)
- Does this proposal fit well with the feel and direction of Swift?
Yes, it matches the general use and reliance on an inferred type system that gives us static-type safety without verbosity outside of conveying the most important information - the interface.
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
This is my first real exposure to this type of feature, outside of the mentioned C++14 auto keyword.
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the whole document, the Generics UI document, and kept-up with both the pitch and first review threads.