[swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Brent Royal-Gordon]

> [Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md ]
> 
> I’m late again to this one, but the discussion’s certainly still going. I’m pretty strongly against the bare ‘A & B’ syntax, for a few reasons:
> 
> - Swift doesn’t use ‘&’ for anything except bitwise AND. In particular, it didn’t get picked for set intersection.

I very, *very* much agree with this point. Thus far, Swift has been very conservative about overloading. It seems bizarre that we would violate that policy for these type combinators when much closer matches have been passed over.

I also think that using `&` absolutely *begs* to have an `|` as well, and as much as the Ceylon people clamor for them, I don't think union types make sense in Swift. Unlike Ceylon, Swift uses an algebraic data type for Optional, doesn't use type-erased generics, and supports overloading. As far as I can tell, *none* of the reasons cited in the Ceylon language design FAQ <http://ceylon-lang.org/documentation/1.2/faq/language-design/> apply to Swift.

(P.S. That language design FAQ is a *fantastic* document.)

> - In theory people are allowed to overload ‘&’ to operate on types. That doesn’t make sense for all types, but you could probably come up with a particular type hierarchy or use of generics where it does make sense.
> 
> - I don’t like types with spaces in them when the spaces aren’t bracketed in some way. This is entirely an aesthetic objection, of the form “I don’t naturally read that as a type, or even as a single unit, when looking at code.” This isn’t a great objection because someone could have said it about `[Int]` or `Int?` as well. (It would be a more realistic objection if some of our brackets weren’t “<" and “>”.)

To augment this: I think that if we're going to see a lot of little `where` clauses attached to types, you kind of have to have a bracketing syntax to put them in. And no, `(Collection where .Element == String)` doesn't count. `()` is about precedence, and this isn't a question of precedence; it's a question of making the type read as a single unit.

> And I still support the ‘Any’ syntax, despite the “order doesn’t matter” problem:
> 
> - It’s consistent with the existing unconstrained ‘Any’ and with the current dedicated wrapper types. If we didn’t think it was a good name for those, we wouldn’t use it there either.

One of my concerns with the `&` syntax is that it leaves no good way to define `Any`. I don't like having a magic `&` operator *and* a magic `Any` keyword, neither of which derives from anything more general.

> - It’s easily learnable. It’s rare enough that someone wouldn’t be exposed to it right away, like Optional, Array, and Dictionary sugar, but when they do see it it’ll be obvious that it’s a type, and probably obvious that it’s special because of the “Any”.
> 
> - It’s a type; types always start with uppercase letters. (This has been said plenty by others.)
> 
> None of these are particularly strong arguments, I know, and I don’t have a good alternate suggestion. But I did want to go on record as being in favor of ‘Any’ and against a binary operator, even though that seems to put me in the minority.

I suspect that at least part of this is simply greater enthusiasm. I know I checked out of this thread for a few days while the `&` guys ran rampant.

(P.S. A thought I had just now: If `Any` is our top type, then `All` would be a good name for our bottom type. And `All<Foo, Bar>` would be a good "All common supertypes of these types" operation. Both of these came up in the variadic generics thread, where we were talking about how to create a type representing any member of a tuple you were trying to splat in.)

-- 
Brent Royal-Gordon
Architechies