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 <[email protected]> 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 >> <[email protected]> wrote: >> >> > On Jun 25, 2016, at 12:00 AM, L. Mihalkovic <[email protected]> >> > wrote: >> > >> > Inline >> > Regards >> > (From mobile) >> > >> >> On Jun 25, 2016, at 1:00 AM, Joe Groff via swift-evolution >> >> <[email protected]> wrote: >> >> >> >> >> >>> On Jun 23, 2016, at 8:55 PM, Jordan Rose via swift-evolution >> >>> <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
