# SE-0244: Opaque Result Types **URL:** \ **Category:** Proposal Reviews\ **Created:** [March 5, 2019, 9:40pm UTC](https://forums.swift.org/t/se-0244-opaque-result-types/21252 "2019-03-05T21:40:52Z")\ **Posts on this page:** 1\ **Showing post:** 69
**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:** [March 11, 2019, 5:58pm UTC](https://forums.swift.org/t/se-0244-opaque-result-types/21252/69 "2019-03-11T17:58:57Z")
> [@orobio](#): > > Exactly this duality tells me we need to design a counterpart to generics. I don't know if there is an existing term for that. Perhaps 'reverse generics'? I wil use this term for the rest of this post. Please correct me if that doesn't make any sense. Indeed, this is pretty much what opaque types boil down to, is the ability for a function to "output" generic parameters in addition to taking them as inputs. Another way we could conceivably notate this is by putting the output parameters after the `->`, as a number of people suggested: ```swift makeFoo() -> F ``` > [@ryansobol](#): > > Opaque types are new to me. As such, one of the aspects if this proposal I’m still having trouble understanding is under what scenarios is an opaque type is preferred over an existential type. Would anyone be willing to write up a brief ELI5 summary? The proposal [tries to explain it](https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md#opaque-result-types-vs-existentials), though the section about it is quite lengthy and I can see how it can be unclear. @Douglas_Gregor, maybe we should go over this section again and try to make it more to the point. @svanimpe's description is a good summary. > [@Chris\_Lattner3](#): > > I have the same position as before - this is an obscure feature that most people will not see very often, and is not a core part of the language that all users should be expected to know to be effective in Swift. Therefore, it makes sense to use a long (and probably compound) keyword for this concept. Using a short name harms 'web searchability' and reduces the odds that someone (who doesn't already know what is going on) can figure out what they keyword is doing without doing that research. > > This is not going to show up pervasively in Swift code, I see no advantage to huffman encoding it down to a 4 character identifier, I'd rather see a 15 character compound name of some sort. I understand the concern about searchability, and I checked—Google does a [fine job providing relevant answers for `swift some` today](https://www.google.com/search?client=safari&rls=en&ei=IpqGXIPlKIue-gSUw5v4CA&q=swift+some&oq=swift+some&gs_l=psy-ab.3..0l2j0i22i30l8.257056.259191..259445...2.0..0.68.671.12......0....1..gws-wiz.......0i131j0i67j0i131i67j0i10j0i22i10i30.2rp9NChvGV8). (There's a legitimate concern that having two `some`s could dilute the waters, I agree.) I however don't agree that this feature will remain obscure for long. The equivalent `impl Trait` feature in Rust is used pervasively; On Github I find [5,000 hits](https://github.com/search?l=Rust&q=%22impl+fn%22&type=Code) for `impl Fn` arguments and returns, [1,000](https://github.com/search?l=Rust&q=%22impl+Iterator+Item%22&type=Code) for `impl Iterator`, and [400](https://github.com/search?l=Rust&q=%22impl+Future+Item%22&type=Code) for `impl Future` alone. Although Swift uses type erasure for function types, obviating the first to some degree, we could deploy this feature for standard library collections as the proposal suggests, and we could well end up with protocol-oriented futures, key paths (and maybe even generic function objects like Rust's, since there are optimizations that enables that our current closure design makes difficult) in the future. Part of the goal of this feature is to make those sorts of libraries easier and more ergonomic to design and use. As for "Huffman coding" the identifier, I have a couple other reasons I think going for something concise that reads well is a good idea. I'd really like to see this feature eventually extend to also allow generic arguments to be written as `some Protocol`, the same way that Rust lets you use `impl Trait` as an argument, since that will make writing a lot of simple generic functions clearer and easier. For this sugar to be worth using, it ought to be at least as concise and readable as the syntax it replaces, and a bulky, obscure keyword would kill that quickly. Furthermore, I also see a bit of a `let` vs `var` situation with regard to existential notation. @dabrahams and others have noted that protocol existentials in their full generality quickly become a rather obscure, complex feature, that doesn't necessarily deserve the pride of place it currently has in our type syntax (and that if anything, opaque types as provided by this feature are in fact closer to what you really want a good percentage of the time we currently tell people to use existentials). Rust eventually decided that making existentials undecorated was a bad idea and added the `dyn` keyword to encourage their use to be explicit. In previous discussions of existential syntax, `Any` or `any` seemed like the clear favorite as the modifier keyword for explicitly introducing an existential. Both linguistically, and in the spirit of fairness of not syntactically biasing one style over the other, `Some` or `some` strikes me as the corresponding modifier for specific opaque types. --- _[View the full topic](https://forums.swift.org/t/se-0244-opaque-result-types/21252)._