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?
>
> -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
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
