Opaque result types

[Vogel]

@John_McCall

We could theoretically statically dispatch the protocol requirements on the opaque type by creating functions that forwarded to the concrete implementations for all of them. That would have terrible code-size costs, though.

Hmmmm, that actually doesn't sound all that terrible to me. It makes sense because ultimately the opaque type would act just like a wrapper type that one could have written themselves.

@John_McCall

We tend to discard that kind of overloading-based argument when considering source compatibility because (1) the examples tend to be highly artificial and (2) it's a kind of argument that can be wielded against essentially any change to the standard library at all, even things as apparently innocuous as adding new methods to existing concrete types (what if the programmer had their own extension that provided an identically-named method with different semantics and slightly more general parameter types such that the new method was preferred?).

In contrast, returning a concrete type instead of an existential seems like a much more plausible source of problems.

That makes sense, but your example with someCollectionOfInts() uses the same mechanic where someCollectionOfInts has two overloads after the change (one synthesized). Therefore I just don't think it makes that big of a difference.

[Jean-Daniel]

@Vogel

Should print "Unspecific function" . Now let's replace the signature:

Shouldn't it print 'Specific function' in both cases.

I though opaque type where just a way to avoid leaking real type to the user, but let the compiler still use the specific type, in that case 'E' in both cases (unlike generalised existential).

[Vogel]

@Jean-Daniel

Shouldn't it print 'Specific function' in both cases.

I though opaque type where just a way to avoid leaking real type to the user, but let the compiler still use the specific type, in that case 'E' in both cases (unlike generalised existential).

No. If the overload behavior would be the same as with the concrete type, you would essentially leak the concrete type, defeating the purpose of the opaqueness. What if we added a completely unrelated function to E?

extension E {
    func g() { }
}

Should this work now?

f().g() //using the opaque version of f

Of course not. g() isn't mentioned in the A protocol, so you can't call it on an opaque A. And the same applies to additional overloads of b(d:).

So the issue that I pointed out stands.

[zwaldowski (Zachary Waldowski)]

Given the Collection confusion — that it's purportedly not a good example for how we'd want to use this first version of opaque types, and that ABI stability saddles the stdlib with its LazyFilterFlattenCrunchyRawUnbonedCollection types — what is the intended, platonic ideal use case? There are lots of examples from forum users about how they'd like to use them, which is good and valuable, but not the same.

I'm not trying to be rhetorical or facetious; if we're moving on to a proposal, such examples are important to how the community receives the proposal. What is this winning us that we don't have? How is this making progress within the Generics Manifesto? If we want impl Trait, why aren't we calling it that? Why would we choose not to lift the well-known and well-complained-about limitations on existentials with associated types to instead explore an allegedly orthogonal feature?

There's a lot of discussion preceding this post about the representational benefits of opaque types, which all sound great and I love, but it's really starting to feel like a cool use of resilience in search of a syntax, and maybe to some extent a solution in search of a problem.

[Moximillian (Mox)]

@zwaldowski

Given the Collection confusion — that it's purportedly not a good example for how we'd want to use this first version of opaque types, and that ABI stability saddles the stdlib with its LazyFilterFlattenCrunchyRawUnbonedCollection types — what is the intended, platonic ideal use case? There are lots of examples from forum users about how they'd like to use them, which is good and valuable, but not the same.

EDIT:
This comment from @nuclearace is enough to convince me that there is a real need for Opaque result types beyond Collection in Foundation. So it makes sense to have a proposal .

[Ben_Cohen]

Hi everyone – this proposal is now in review over here.

[Joe_Groff]

Collection happened to be a convenient preexisting hierarchy of protocols and lazy wrapper types that motivates the feature well. It's not the only use case by any means; in Rust, the impl Trait feature is also used heavily with their Future design, which is also based around implementations of a common Future protocol with a library of adapters. If we ever moved to "protocol-oriented" key paths, with KeyPath being a protocol with a variety of concrete implementations and transformation wrappers, it would also make sense to apply there.

To try to better motivate the feature, I added another, non-Collection example to the latest draft of the proposal.

[Douglas_Gregor]

Oops, we're in the pitch thread. @Tino, you might want to bring this up in the review thread, probably with the _ bit (or something like it) to address @gwendal.roue's concern

• Doug

[Ben_Cohen]

I moved this exchange over to the review thread.

[gwendal.roue (Gwendal Roué)]

I do not dare having a "concern" about the Opaque result types topic. There are already a lot of smart people discussing the subject. But I found Tino's idea refreshing, and you were able to save it from an immediate drowning!