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