In the previous review thread, I said:
I'm in favor of the feature and I think the proposal covers enough ground to be a useful addition to the language.
However, the vague syntax suggestions in the "Future Directions" section concern me. I'm worried that the
-> some Psyntax may be adequate for this proposal's purposes, but may not extend cleanly to uses we envision in the future. Maybe there is some larger scheme we could fit thesomesyntax into; if so, I'd like to see a sketch of that scheme before we commit to it here. (More thoughts on that in theProtocol<.AssocType == T>thread.)Otherwise, I support it.
The "generics UI manifesto" has addressed my future-directions-related concerns and I support its overall vision. I also still support the feature itself.
I'm a little hesitant about the decision to introduce the some syntax with this proposal and defer the full "reverse generics" syntax for later, but I ultimately think it's the right decision. Once we support (...) -> <T: P> T syntax, people will immediately try to use it in ways the current implementation doesn't support. It would be a poor experience for users to have so many different things be straightforward to express but unsupported, and I don't think it makes sense to delay opaque result types until they can support every bell and whistle the generics system has to offer. Therefore, shipping opaque result types with only the some syntax is our best option.
I look forward to seeing some of the other results of the generics UI manifesto. some in parameter position seems like especially juicy and low-hanging fruit—I've had to explain to several different people why inout P parameters don't do what they want, and inout some P would be a very nice solution to offer them.