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

[Matthew Johnson]

Sent from my iPad

> On Jun 1, 2016, at 4:18 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.

I'm neutral on the syntax.  But I strongly believe removing the ability to use protocol / Any in generic constraints *must* be accompanied by the introduction of a new (hopefully more robust) mechanism for factoring out common generic constraints.

> 
> 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
> 
> _______________________________________________
> 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/60f07321/attachment.html>