[swift-evolution] [Pitch] Rename protocol<> to Any<>

[David Waite]

> On May 19, 2016, at 1:11 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Austin do we really need this 3rd proposal? This makes my original one really a waste of time. I was trying to solve https://openradar.appspot.com/20990743 <https://openradar.appspot.com/20990743> with the original `Any<>` proposal when Swift 3 ships. Your other proposal would enhance it without introducing breaking changes.
> 
>> To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.
> 
> Why would these cause warnings?
> 
> func foo(any: protocol<>)
> 
> func foo(any: protocol<Any>)
> 
> func foo(any: protocol<Any, ProtocolA>)
> 
> func foo(any: protocol<ProtocolA>)
> 
> Everything is already fine today.
> 
> 
I assume you meant to use Any and not protocol above.

They can all be interpreted, but:
- they provide multiple ways of expressing the same concept
- the additional uses of Any detract from code clarity
- it is possible (in the absence of an established design) that these syntaxes (particularly Any<Any<ProtocolA>>) might limit our ability to add existential types without either breaking existing code or adding special cases in the parser. I can go into more detail on my reasoning here, but that seems a diversion of this topic to do so.

An example elsewhere in the language of otherwise valid code being rejected because the syntax is redundant:

enum MyError:ErrorType, ErrorType {}

I’m also specifically saying that the *syntax* should warn on the use of Any-within-Any. Code such as:

typealias Foo = Any
typealias Bar = Any<Foo, Sequence>

would be fine.

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160519/3fb406bc/attachment.html>