[swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `P1 & P2`

[L. Mihalkovic]

> On Jun 24, 2016, at 6:04 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Jun 23, 2016, at 22:20, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
>> 
>> 
>> Regards
>> LM
>> (From mobile)
>> On Jun 24, 2016, at 5:55 AM, Jordan Rose via swift-evolution <swift-evolution at 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.
>>> 
>>> 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.
>> 
>> This is another way to generalize P&Q compositions that opens another way to specify WHERE
>> 
>> 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

Thank you for reading.

Originally i wanted to make "[" and "]" be CONSTRAINT_BEGIN and CONSTRAINT_END respectively to signify that what mattered was the overall structure and how it degenerated into this syntax when the composition is not applied to a concrete type (i.e. naked P&Q), as well as show that this gave a formal definition to Any: a zero term composition that is not limited to a single concrete type, otherwise spelled "_ CONSTRAINT_BEGIN CONSTRAINT_END"

Anyhow, it was an interesting mental exercise.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160624/d26dd545/attachment.html>