> On Jun 23, 2016, at 22:20, L. Mihalkovic <[email protected]> wrote:
>
>
> Regards
> LM
> (From mobile)
> On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> [Proposal:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md
>>
>> <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.
>>
>> However, I did remember one issue, which was brought up on the previous
>> mega-thread: if we do want to generalize protocol values
>> <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials>,
>> 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
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>.)
>>
>> 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.
>
> This is another way to generalize P&Q compositions that opens another way to
> specify WHERE
>
> https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051
> <https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051>
Thanks for bringing this up. I know one reason we’ve avoided syntax like this
in the past is the potential for static subscripts, but of course that’s just
one of many future concerns.
Jordan
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
