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

Austin Zheng austinzheng at gmail.com
Wed Jun 1 16:18:48 CDT 2016

After thinking about this topic for the past few days, I'd like to throw in
my support for "Any<>" as well. It's one magic construct to learn, looks
like a type, has the visual delineation, and shares continuity with both
protocol<> and Any today.

I'd also like to express my support for the proposal to delineate generic
and existential syntax: all existentials must be written with Any<...>;
generic type constraints cannot use it. I hope this will make it clear to
people learning and using the language that, despite their superficial
similarities, they are actually two different concepts.


On Wed, Jun 1, 2016 at 1:59 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> > [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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160601/743c1ec2/attachment.html>

More information about the swift-evolution mailing list