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

[Austin Zheng]

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 :).

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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/20154e37/attachment.html>