Sent from my iPad
> On Jun 24, 2016, at 6:00 PM, 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. Would this syntax have the same semantics as the current generics syntax? That would be very cool - it is much more elegant. > > -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
