# SE-0244: Opaque Result Types (reopened)

**URL:** <https://forums.swift.org/t/se-0244-opaque-result-types-reopened/22942>\
**Category:** Proposal Reviews\
**Created:** [April 10, 2019, 11:10pm UTC](https://forums.swift.org/t/se-0244-opaque-result-types-reopened/22942 "2019-04-10T23:10:48Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![beccadax](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/beccadax/32/34217_2.png) [@beccadax](https://forums.swift.org/u/beccadax)\
**Post date:** [April 11, 2019, 11:04pm UTC](https://forums.swift.org/t/se-0244-opaque-result-types-reopened/22942/17 "2019-04-11T23:04:15Z")

</div>

In the previous review thread, [I said](https://forums.swift.org/t/se-0244-opaque-result-types/21252/5):

> 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 P` syntax 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 the `some` syntax into; if so, I'd like to see a sketch of that scheme before we commit to it here. (More thoughts on that [in the `Protocol<.AssocType == T>` thread](https://forums.swift.org/t/protocol-assoctype-t-shorthand-for-combined-protocol-and-associated-type-constraints-without-naming-the-constrained-type/21217/10).)
> 
> 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.

---

_[View the full topic](https://forums.swift.org/t/se-0244-opaque-result-types-reopened/22942)._
