- What is your evaluation of the proposal?
A general +1 from me. I’m not an expert on the topic but there has been more than one occasions where this feature would have helped.
- Is the problem being addressed significant enough to warrant a change to Swift?
Yes. In general I think every little step to an improved type system (see the generics manifesto) is good for the language expressivity in the long term. Sometimes I needed to just return an instance of a protocol without really caring about the specific types and it gets cumbersome really quickly.
- Does this proposal fit well with the feel and direction of Swift?
The proposal expresses the problem really well and it’s really well written. I have to admit that every time I read it I start thinking that it would be nicer to just “-> P” instead of including a new keyword, but after reading it I’m convinced of the reason. Is still tricky to grasp the full theory of this type system functionalities and how it compares with generalised existential types. Luckily the proposal gives good examples and clarifies how this features differ.
That said I prefer
some. While reading the code “some” seems to be too ambiguous to me, it doesn’t really seem so different as “any”. “opaque” seems much more appropriate to me and much more clear. Maybe is because it reminds me to when you refer to opaque return values on C. But I guess I can get used to “some” if native speakers and language experts say is more appropriate.
A concern I have is about the future directions needing more syntax changes. I’m concern we put ourselves in a corner in terms of syntax, and that if we would look into it holistically we may find a better solution. Again, if more knowledgable people says is fine let’s go for it, I just wanted to raise my concern that maybe is worth taking a look at those future directions now.
Somewhat tangent to the proposal but I think is important is the error messages around this feature. Type errors can be really confusing (specially in Swift early days) and it would be unfortunate to go back to that state with this feature, specially since opaque types don’t have names. Even for experienced developers some times parsing error messages gets hard.
Finally, is there any concern about type inference? Sometimes type inference can’t resolve some expressions and adding types helps the compiler, but in this case there won’t be a type to add so maybe the user is stuck? Just throwing it out there.
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
The Rust community has gone trough similar path for their type system. I’m glad the proposal is aware of this and acknowledges their learnings.
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I’ve been following the pitch thread since it was posted and I’ve read the proposal multiple times. I haven’t tried the toolchain.