> 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.
-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
