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

Sat May 21 07:13:17 CDT 2016

One more thing, I would also add the ability to allow something like this:

protocol A {}  
protocol B {}

// Here `type` can be `protocol`, `class`, `struct` or `enum`.
type C: any<A, B> {}
Where today is only possible to express something like this:

protocol A {}  
protocol B {}

typealias AB = any<A, B>

// Here `type` can be `protocol`, `class`, `struct` or `enum`.
type C: AB {}
This is a lack of functionality.

-- 
Adrian Zubarev
Sent with Airmail

Am 21. Mai 2016 bei 05:16:24, Matthew Johnson via swift-evolution (swift-evolution at swift.org) schrieb:

On May 20, 2016, at 10:07 PM, Austin Zheng <austinzheng at gmail.com> 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 <matthew at anandabits.com> wrote:

On May 20, 2016, at 9:10 PM, Austin Zheng <austinzheng at gmail.com> 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 <austinzheng at gmail.com> 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

Best,
Austin

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160521/e209bb5e/attachment.html>