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

[Austin Zheng]

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/add2e2f0/attachment.html>