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

[Austin Zheng]

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.

Austin


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>