> On May 20, 2016, at 10:07 PM, Austin Zheng <[email protected]> wrote: > > These aren't really my points, I just copied them out of the other > sub-thread. I'm sure there will be a separate review period, during which > many more people will probably join in with their opinions :).
I understand that. You asked for any other thoughts before you update your proposal. I am sharing my thoughts. :) Feel free to use them in the proposal if desired. > > Austin > > On Fri, May 20, 2016 at 7:59 PM, Matthew Johnson <[email protected] > <mailto:[email protected]>> wrote: > >> On May 20, 2016, at 9:10 PM, Austin Zheng <[email protected] >> <mailto:[email protected]>> wrote: >> >> (Trying to move the conversation back to this thread to un-hijack Adrian's >> thread.) >> >> In terms of Any<> vs any<>, I don't have any strong feelings and I think >> there are good arguments on both sides. I'm going to leave the proposal as >> Any<> but put a section in the 'Alternatives' discussing Any<> vs any<>, so >> that if it does go up for review the core team can review arguments and >> maybe choose one they like. > > Thanks for the summary. I think this is helpful. > >> >> Any<> pros: >> - The convention is to capitalize types. 'Any<A, B>' is immediately apparent >> as a type, and looks like a type when used in places where types would be >> used (like function signatures) >> - Having 'Any<>' allows us to keep the well-established 'Any' without having >> to typealias to 'any' or 'any<>’ forms > > How so? you can’t just use `protocol` naked today. You have to say > `protocol<>`. `Any` is a typealias for that. This means we either have a > typealias, we type out `Any<>` or we type out `any<>`. We don’t get to just > type `Any` or `any` without a typealias just because we change the keyword. > > And I do agree that typealias for existentials should be capitalized. These > are types and behave identically to any other type. > >> - any is a keyword, but an argument can be made that keywords that fit into >> a particular syntactic slot should be capitalized like normal members of >> that slot. Any<> fits into the slot of types, so it should be named like a >> type >> - In the future, AnySequence and friends can be replaced with, e.g. >> Any<Sequence>. >> This increases discoverability of existential features, like a future >> "Any<Sequence where .Element == Int>". A number of developers have mentioned >> that they suspect protocol<> is rarely used, although GitHub's search makes >> it impossible to quantify. > > If protocol<> is rarely used it is probably because it is a very limited > feature at this point. It becomes extremely useful when we can constrain > associated types. > > When that is possible and the community shares knowledge about how to use it > it will become a widely used feature. I don’t think upper / lower case or > `typealias AnySequnce<T> = Any<Sequence where .Element == T>` will make much > difference either way. > >> >> any<> pros: >> - any<>'s lower case 'a' distinguishes it from other generic types that use >> similar syntax, such as "Array<Int>". Perhaps developers, especially those >> new to Swift, will be confused as to why "Any<A, B>" isn't a generic type, >> but "Dictionary<A, B>" is. > > The reason this is important is that generic types can be used in ways that > Any cannot. Thus the likely point of confusion is why the following is not > valid: > > struct Foo<T, U> { > func foo(bar: Any<T, U>) { ... } > } > > If we use lowercase it gives the user a hint as to why they might not be able > to use it in all of the same ways as a generic type, especially because Swift > is developing strong and consistent conventions for keywords. If we use > uppercase here, not only do we introduce potential confusion in this case, we > also water down the meaning of those conventions and make the language > slightly less predictable. (i.e. users might wonder: are there other > uppercase generic-type-like constructs that don’t quite behave like normal > generic types?) > >> New developers aside, it may be jarring to have to mentally 'context switch' >> between Any<A, B> as an existential, and AnythingButAny<A, B> as a generic >> type. >> - any's lower case 'a' makes it clear to users it's not a 'normal' type, but >> rather a construction that can be used as a type in some cases, and can't be >> used everywhere a concrete type can. > > Existential types can be used anywhere concrete types can. The difference is > that Any as a type constructor behaves much differently than other type > constructors (generic structs, enums, and classes). > >> - 'any' isn't a specific type - it's a kind of type (an existential), and >> this spelling fits better with the other 'kind' names: 'class', 'struct', >> 'enum', 'protocol' >> - any is a keyword, and keywords are lower case. Perhaps consistency in this >> matter is more important. >> >> Any other thoughts? I will submit an amendment tonight if people are okay >> with this. > > I have one additional thought. Brent’s rule is based on *exempting* keywords > from the usual rule of lowercase. IMO that exemption should be reserved for > cases where the keyword in question can be used in all of the same was that > the similar syntactic form can be used. I believe the fact that this is not > the case for Any is a strong argument to preclude it from receiving the > exemption. > > To be perfectly honest, I do prefer `Any` from an aesthetic / readability > standpoint. But I also think the consistency and usability arguments point > in the other direction. > > When all has been decided I will happily use whatever is decide in my own > code. :-) > >> >> Austin >> >> >>> On May 18, 2016, at 10:35 PM, Austin Zheng <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hello all, >>> >>> 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 >>> >>> <https://github.com/austinzheng/swift-evolution/blob/az-protocol-to-any/proposals/XXXX-any-as-existential.md> >>> >>> Best, >>> Austin >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
