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

[L. Mihalkovic]

As i said, already deeply regretted mentioning P|Q as on closer examination of a well known precedent it is very realistic to have P&Q only.
Apologize again for not doing the due dilligence before pressing send.
(From mobile)

> On Jun 27, 2016, at 7:04 PM, Austin Zheng <austinzheng at gmail.com> wrote:
> 
> I think the rationale thread for the original version of this proposal pretty much shut down the possibility of disjunctive type constraints. In fact, the primary argument against '&' was that it would encourage conversations about '|'.
> 
> It's also been added to the commonly rejected proposals list: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
> 
>> On Mon, Jun 27, 2016 at 9:48 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> > On Jun 25, 2016, at 12:00 AM, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
>> >
>> > Inline
>> > Regards
>> > (From mobile)
>> >
>> >> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> >>
>> >>
>> >>> On Jun 23, 2016, at 8:55 PM, Jordan Rose 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’ve gone on record before as against this syntax, although when I set out earlier today to record my usual rebuttal I found that it really was mostly a matter of taste. Yes, this looks weird to me:
>> >>>
>> >>> let callback: (Data) -> NSCoding & NSCopying
>> >>>
>> >>> but I’m sure the infix ‘->’ for functions looked weird to everyone the first time they saw it as well, and it really is pretty clear in argument position.
>> >>
>> >> We could conceivably bracket the 'where' constraints somewhere. It's nice not to have to punish the common case syntax. In my personal ideal vision of the world, I'd like to see us support opening existentials via path-dependent types (e.g., let a: Collection; let element: a.Element). If we support them in decl-level 'where' clauses, we provide a nice, clean syntax for complex generic relationships that doesn't require angle brackets or per-existential where clauses at all, something like:
>> >>
>> >>   func intersect(a: Collection, b: Collection) -> Collection
>> >>       where a.Element == b.Element, b.Element == return.Element {
>> >>   }
>> >>
>> >> which doesn't completely define away the need for 'where' as part of existential types, but would shrink it quite a bit.
>> >
>> > For some reason it had not clicked until your 'path dependent type' reference how reminicent of (U+00B7) this is. I watched nada's 2014 presentation again... but then it means intersection types would add a lot... you guys seem ok to add P&Q now, so why not take that opportunity to allow P|Q at the same time. Does it also mean that you might consider at some point expanding 'assoctype U'  into:  T where <:U , :>U  opening the door to lower/higher type bounds?
>> 
>> Let's not rathole on the P|Q thing. Disjunctions are difficult to make much sense of in a parametric type system like ours; there are plenty of other threads on this mailing list discussing it.
>> 
>> -Joe
>> _______________________________________________
>> 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/20160627/d3addbcb/attachment.html>