> On May 19, 2016, at 1:11 AM, Adrian Zubarev via swift-evolution
> <[email protected]> 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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
