I think this is a good idea - the implementation of Any ( = Any<>) should not be specified to be a typealias. (And this would resolve the idea Colin brought up.)
To David's points (to avoid clogging up the list): - 'Any' is still valid, and has the same meaning as it did before. - 'Any<>' should be allowed. You can currently use 'protocol<>' in your code instead of 'Any'. - 'Any<Any>' behaves exactly the same as 'protocol<Any>' today, which is just 'Any'. - There are at least two proposals floating around the list that expand how 'Any<>' can be used. 'protocol<>' is sort of a weird Swift construct with no good equivalents elsewhere in the language, and I don't know if it would be strictly correct to call 'protocol' a keyword in this case. Austin > On May 18, 2016, at 10:52 PM, Brent Royal-Gordon <[email protected]> > wrote: > >> Swift 3.0 focuses on making breaking changes that prepare the way for >> features to be introduced in future releases. In that spirit, I would like >> to solicit feedback on a very simple proposal: renaming 'protocol<>' to >> 'Any<>', as described in the 'Completing Generics' manifesto. >> >> The proposal can be found here: >> https://github.com/austinzheng/swift-evolution/blob/az-protocol-to-any/proposals/XXXX-any-as-existential.md > > One small thing: > >> Any<> should be typealiased to Any. > > > I'm not sure if it's better to specify that this should be a typealias, or > simply that `Any` without angle brackets is equivalent to `Any<>`. I worry a > little about whether Swift might have trouble parsing `Any<Foo>` if there's > an `Any` typealias lying around. > > -- > Brent Royal-Gordon > Architechies > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
