SE-0309: Unlock existential types for all protocols

[filip-sakel]

@1oo7

The Swift style guide says that protocols should have a name that makes it clearly a protocol—an adjective or gerundive describing the capability or behavior represented by the protocol requirement: Hashable , Comparable , etc. This is not compiler-enforced syntax, but there is seldom any confusion about what is a protocol and what isn't.

OK.

@1oo7

Existing Swift gives constraints an explicit syntax; it's clear they are not the same thing as using a protocol as a type. Consider:

protocol Processable {}
protocol Usable {}
func process<T: Processable>(_ item: T) -> Usable 

Processable is being used as a constraint, and Usable is not. It's not ambiguous.

Many Swift users don't know the difference between func f<T: P>(parameter: T) and func f(parameter: P) — I too was one of those people at some point. The confusion stems from the lack of an indication that parameter is bound to the existential type of P; any P should hopefully change that.

@1oo7

That's more ambiguous, not less, because now it makes sound like Usable is a constraint on any type that gets returned by the function, just like View is a constraint on some View that gets returned by a SwiftUI body. However this function won't return just "any" concrete type that conforms to Usable , it will always return the same exact type: Usable (the existential).

Do you mean that users could perhaps conflate () -> any Usable and <^T: Usable>() -> T — the latter syntax is borrowed from here?

To me, the any-some distinction, between existentials and generics respectively, makes sense. Namely, some Hashable indicates that a value of some (a singular, specific) Hashable-conforming type will be returned. On the contrary, any Hashable indicates that any (an unspecified type, not always the same) Hashable-conforming type can be returned (and wrapped in the existential), meaning we can do this: (Bool.random() ? "" ? 0) as any Hashable but can't do the same with some.

@1oo7

I agree it's confusingly worded, but it's not a paradox. There are other ways to explain this, where it makes perfect sense.

That was metaphorical, but unfortunate wording on our part, nonetheless.

@1oo7

I don't think syntax "tempts" people. It's just syntax. We should avoid the temptation to use syntax to prescribe behaviors.

I disagree. Syntactic friction can encourage certain styles and discourage others; for example, requiring that existentials be written out as ThisIsAnExistentialOfProtocol<Hashable> would result in many preferring <T: Hashable> T where possible, choosing the path of least resistance.

@1oo7

If we are seeing people avoiding using certain language features, or being confused by them, I think it means we could do a better job of documenting the language & educating Swift developers about how the compiler and runtime work. I'd note that @xwu and their team has done a really excellent job of this lately, and as well there's a lot more resources available for learning the intricacies of Swift than there were a few years back.

Documentation can help but it's not enough.

@1oo7

By removing many of those errors, your proposal will unblock more people from using these features—no syntax change needed.

To be clear, we don't propose altering the existential syntax; let a: any Hashable will be invalid.

@1oo7

var foo: Proto<Fooable>

Swift tends to avoid abbreviations.

@1oo7

• var foo: Object<Fooable>
• var foo: dynamic Fooable

I think these would be poor name choices.

@1oo7

I like Object<Fooable> because it makes it obvious that protocol-type objects will incur reference semantics just like any other object (yes there are some exceptions but they're basically just a compiler optimization when the object is tiny). It also makes it obvious that we're dealing with a concrete type that allows no further generic specialization, and from which no further static type information can be "opened" without dynamic casting or type erasure schemes.

The only benefit I see to Object<Protocol> is the fact that it's a concrete type; however, that would be undermined if we enabled func f(_: Optional<some Hashable>). Nevertheless, I don't think naming should be based on implementation details (existentials don't have reference semantics — mutating one doesn't change another), not to mention that many users would think that Object is referring solely to classes. (If we use this syntax, then Array which isn't backed by value types, should be called ArrayObject.)