> On Jun 25, 2016, at 9: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?
My point was that the dots (pun intended) are starting to connect and I think it is a neat path to follow. Strike union type as the first use case is already addressed, and it would no matter what be a larger additive. I would love to see a future with type bounds, and although the implementation would be a massive delta, the syntax change would be very minimal. I will play more with my little syntactic exercise to see what a grammar might look like following your train of thoughts. https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051 >> >> -Joe >> >>> However, I did remember one issue, which was brought up on the previous >>> mega-thread: if we do want to generalize protocol values, we’re going to >>> want something that’s essentially “a type with a ‘where’ clauses in it”. I >>> really don’t want to force people to use a typealias to spell such a type, >>> but at the same time I want that where clause to be clearly attached to the >>> type. (As brought up before the return position of a function is currently >>> ambiguous with SE-0081.) >>> >>> Despite the lightweightedness and the well-prepared proposal by Adrian and >>> Austin, the lack of bracketing <> () {} [] leads me to maintain my stance >>> against the proposed syntax. >>> >>> Jordan >>> >>> _______________________________________________ >>> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
