# SE-0360: Opaque result types with limited availability **URL:** \ **Category:** Proposal Reviews\ **Created:** [May 31, 2022, 6:58pm UTC](https://forums.swift.org/t/se-0360-opaque-result-types-with-limited-availability/57729 "2022-05-31T18:58:24Z")\ **Posts on this page:** 3\ **Page:** 2
**Author:** ![xedin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/xedin/32/309_2.png) [@xedin](https://forums.swift.org/u/xedin)\ **Post date:** [June 6, 2022, 11:04pm UTC](https://forums.swift.org/t/se-0360-opaque-result-types-with-limited-availability/57729/21 "2022-06-06T23:04:17Z")
> [@jechris](#): > > Edit: re-reading the proposal the availability check is done at runtime. So I think it's the right way. Just maybe make sure to have a clear error message on why it will fail to compile in some use cases. Currently the message is the same but it's definitely reasonable to use a tailored one for cases like this. Please share if you have something in mind already. ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [June 20, 2022, 12:55pm UTC](https://forums.swift.org/t/se-0360-opaque-result-types-with-limited-availability/57729/22 "2022-06-20T12:55:09Z")
Late to reviewing this proposal; I'd put it off as there were modifications upthread for clarity in flight, and then the time got away from me! I agree that the proposal is sensible, but I do have some quite serious concerns about the understandability of the text: * * * To start, I'll point out again that I still think @jrose's formulation of the principle in the pitch phase is the clearest explanation of this feature: > [@\[Pitch\] Opaque result types with limited availability](https://forums.swift.org/t/pitch-opaque-result-types-with-limited-availability/57286/3): > > I think the underlying principle here is that > > > a function returning an opaque result type _must return a value of the same concrete type `T`_ from each `return` statement > > is a condition that does not have to apply across executions of the same program, the same way that Hashable must produce the same output for the same value during program execution, but may produce a different value in the next execution. `#available` is special because it's a checkable form of that: dynamic availability will not change while the program is running, but may be different the next time the program runs. I would be strongly in favor of incorporating that text or some version of it explicitly in the proposal, _not_ in the Introduction section where it's currently been worked in but rather _as part of the proposed solution_—_even if_ it's desired for any future expansion to be put through the Evolution process separately (that can be spelled out too). As it is, the text still emphasizes that the proposal aims to allow the return of _different_ types, when really (as @jrose clarifies above so elegantly) it is just expanding the compiler's understanding of when code will in fact return the _same_ type. I think @Jon_Shier's immediate impression that this proposal "violate[s] the single return type rule" is emblematic of how readers will misunderstand the proposal text without digging through this forum, and I'm concerned what that will do to long-term understanding of what we are setting out to do. I also have concerns about the terminology: while it's technically true that we can always clarify our terms ("in this text, when I write _x_, I mean _y_"), I think it's a barrier to reader understanding to define something spelled with `if #availability` as an "unconditional availability." The term directly contradicts what the spelling tells us, namely that it is a _condition_ about _availability_. What the author must mean here is either (1) that there are no _other_ conditions _but_ availability (i.e., no dynamic conditions), and/or (2) that within that conditional availability clause the code _unconditionally returns_ the _same_ type. I will say that the Detailed design section in the proposal does a very nice job of closely tracking how someone might think about how to implement the feature and its exact proposed limits. However, because the text describes what's _conditional_ as _unconditional_ and it explains its rules about returning the _same_ type per execution as an expansion to allow returning _different_ types, it is very difficult for the reader to reach an understanding of _why_ the feature is designed the way it is. One consequence is that readers won't grasp which parts of the rules and limitations laid out are inherent to the principle above and which are subject to future expansion due to (possibly temporary) implementation limits. * * * Anyway, concerns about the expository choices here aside, I think the expansion is a sensible one and the implementation limits are reasonable as-is. I think this is a very sensible improvement that fits with the overall feel and direction of Swift. ---
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [July 5, 2022, 7:09pm UTC](https://forums.swift.org/t/se-0360-opaque-result-types-with-limited-availability/57729/23 "2022-07-05T19:09:48Z")
Thank you everyone for helping review this proposal! The Language Working Group has decided to [accept this proposal](https://forums.swift.org/t/accepted-se-0360-opaque-result-types-with-limited-availability/58712). [Previous page](https://forums.swift.org/t/se-0360-opaque-result-types-with-limited-availability/57729.md?page=1)