Inline Regards&Apologies LM (From mobile)
> On Jun 27, 2016, at 6:48 PM, Joe Groff <jgr...@apple.com> wrote: > > >> On Jun 25, 2016, at 12:00 AM, L. Mihalkovic <laurent.mihalko...@gmail.com> >> wrote: >> >> Inline >> Regards >> (From mobile) >> >>> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>>> On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution >>>> <swift-evolution@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. Already retracted the P|Q as bringing absolutely nothing required in the foreseeable future. Apologies again for not having the presence of mind to see it before clicking send. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
