Unlock Existential Types for All Protocols

[filip-sakel]

This proposal aims to add support for existential types derived from any protocol.

Forums Thread: https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025

Implementation: swiftlang/swift#33767

[theblixguy]

Looks great! I think we can pitch it on the forums soon once all suggestions above (plus ones mentioned in forums private messages, like warnings about compositions with conflicting constraints) have been addressed, in order to start collecting any feedback.

[benrimmington]

You'll need to change the base branch of this pull request to main.

[AnthonyLatsis]

What do you guys think? Unless you have been planning to add something, I think we're set up to ask Joe to schedule the SE review after this session.

[theblixguy]

What do you guys think? Unless you have been planning to add something, I think we're set up to ask Joe to schedule the SE review after this session.

Sounds good! I’ll have another look at it today (sorry, I had taken a break from compiler/SE contributions but I’m back now) & then I think it should be good to go!

[filip-sakel]

I had been quite busy too; now, though, I have more free time. So, yes, I think we can request a review or create a pitch thread — I'm not sure if we should first do the latter.

[filip-sakel]

Do you think that we should add a future direction for opening an existential, and then wrapping it into a type-erasure container? For instance, init(_ box: Hashable) could be added to AnyHashable. I'm not sure, though, if this addition could be briefly stated in an existing section, or if we'd have to create a new one.

[AnthonyLatsis]

There's a bullet point for "automatically opening existentials when passed as generic arguments" at the bottom. That would allow the generic initializer of AnyHashable to accept a Hashable value.

[filip-sakel]

That would require some implementation work; at the same time, users will be left unable to initialize standard-library-provided type erasers with their language-provided protocol counterparts. I'm not sure if this feature should be part of the proposal, because I think it could create a major usability issue, due to the lack of a feature that can be easily added to the standard library.

Sorry, if I've missed some aspect of the proposed feature that already enables this behavior.

[AnthonyLatsis]

Sorry, the part about "automatically opening existential values" is a future direction (it was also mentioned as such a couple of times in the forums); we are not proposing or implementing it now.

users will be left unable to initialize standard-library-provided type erasers with their language-provided protocol counterparts.

In case this is still relevant — why is that? Self-conformance does allow you to initialize an AnyProtocol wrapper with a Protocol value, among other stuff.

[filip-sakel]

I wasn't very clear.

I'm arguing that implementing "self-conforming" existential types would require some implementation work, which is — obviously — not in scope for this proposal.

Yet, the current proposal (without self-conformance) creates serious usability issues — provided that I haven't missed anything — since users will be unable to write something like AnyHashable(1 as Hashable).

What I propose we do, is include:

extension AnyHashable {
  public init(_ box: Hashable) {
    self = _openExistential(box, do: { unboxed in
      AnyHashable(unboxed)
    })
  }
}

Similarly, we could provide such an initializer for AnyCollection and any other type-erasing, standard-library wrappers.

[filip-sakel]

I see. But AnyCollection is not really an option, because we need to somehow represent the Element type once we get the wrapper back.

Right. This, then, leaves us just with AnyHashable.

I have mixed feelings about a permanent workaround to a temporary issue, given that users can add the workaround themselves if they happen to need a new Hashable -> AnyHashable conversion in the meantime. You are totally welcome to add it as a future direction though.

I understand your concern. I think whether a workaround will be implemented depends on the timing of the follow-up proposal for automatically opening existentials.

How about the following for a future direction bullet:

Add an init(_ box: Hashable) initializer to AnyHashable to alleviate confusion and aid in usability. This initializer should be treated as a workaround, and removed once automatic opening of existential types becomes available.

[AnthonyLatsis]

Sounds fine, but

...and removed once automatic opening of existential types becomes available.

this would break the ABI (we cannot remove something public once added).

[filip-sakel]

Yeah, I meant "deprecated". Then, after a major version of being deprecated, it could be removed — if that's an option. That, of course, entails that init(_ box: Hashable) be marked @_disfavoredOverload, in addition to deprecated.

Is this okay?

Add an init(_ box: Hashable) initializer to AnyHashable to alleviate confusion and aid in usability. This initializer should be treated as a workaround, and deprecated once automatic opening of existential types becomes available.

[AnthonyLatsis]

• "should" -> "would"
• "once" -> "if/when"

LGTM.

[filip-sakel]

I just changed if/when ... becomes available to should ... become available.

[AnthonyLatsis]

So, yes, I think we can request a review or create a pitch thread — I'm not sure if we should first do the latter.

I reckon we're fine with two pitch threads and that much discourse 🙂.

[theblixguy]

Looks fantastic! I only have some very minor comments!

[jckarter]

I appreciate it, but I don't think I really need author credit for this.