[Pitch] Rename protocol<> to Any<>

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:

Best,
Austin

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

I’m a fan (mostly because I think it helps existential types, which have blocked quite a few library projects of mine), but I do have a few questions about the impact of the proposal

- I assume ‘Any' is still valid?
- In that case, would 'Any<>' be equivalent to ‘Any’, or a warning/error?
- What about 'Any<Any>' and such combinations?
- Does Any eventually become a keyword to deal with these sorts of special cases, the unbounded generic parameters, as well as future existential type uses (such as including a ‘where’ clause)?

-DW

···

On May 18, 2016, at 11:35 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

(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.

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

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. 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.
- '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.

Austin

···

On May 18, 2016, at 10:35 PM, Austin Zheng <austinzheng@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

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 <brent@architechies.com> 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

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

···

On May 20, 2016, at 9:10 PM, Austin Zheng <austinzheng@gmail.com> wrote:

Austin

On May 18, 2016, at 10:35 PM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@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

There's no need for this, that's what I was trying to get across. It's (likely) a special case in the grammar right now. If we eliminate Any<>, from the point of view of syntax, both Any and Any<Foo, Bar> are just a built in type and normal application of generic arguments (to a built in type).

-Colin (via thumbs)

···

On May 19, 2016, at 1:58 AM, Austin Zheng <austinzheng@gmail.com> wrote:

- 'Any<>' should be allowed. You can currently use 'protocol<>' in your code instead of 'Any'.

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@anandabits.com> wrote:

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

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.

···

On May 20, 2016, at 10:07 PM, Austin Zheng <austinzheng@gmail.com> wrote:

Austin

On Fri, May 20, 2016 at 7:59 PM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:

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

Does anyone want to speak up in favor of 'Any<>'? The more I think about it the more I think 'Any' should just be the single, canonical form.

Austin

···

On May 18, 2016, at 11:33 PM, Colin Barrett <colin@springsandstruts.com> wrote:

There's no need for this, that's what I was trying to get across. It's (likely) a special case in the grammar right now. If we eliminate Any<>, from the point of view of syntax, both Any and Any<Foo, Bar> are just a built in type and normal application of generic arguments (to a built in type).

-Colin (via thumbs)

On May 19, 2016, at 1:58 AM, Austin Zheng <austinzheng@gmail.com> wrote:

- 'Any<>' should be allowed. You can currently use 'protocol<>' in your code instead of 'Any'.

My feedback is that we should narrow what is acceptable for Any as much as possible, because relaxing restrictions in the future won’t break existing code.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.

-DW

···

On May 19, 2016, at 12:43 AM, Austin Zheng <austinzheng@gmail.com> wrote:

Does anyone want to speak up in favor of 'Any<>'? The more I think about it the more I think 'Any' should just be the single, canonical form.

Austin

On May 18, 2016, at 11:33 PM, Colin Barrett <colin@springsandstruts.com> wrote:

There's no need for this, that's what I was trying to get across. It's (likely) a special case in the grammar right now. If we eliminate Any<>, from the point of view of syntax, both Any and Any<Foo, Bar> are just a built in type and normal application of generic arguments (to a built in type).

-Colin (via thumbs)

On May 19, 2016, at 1:58 AM, Austin Zheng <austinzheng@gmail.com> wrote:

- 'Any<>' should be allowed. You can currently use 'protocol<>' in your code instead of 'Any'.

Austin do we really need this 3rd proposal? This makes my original one really a waste of time. I was trying to solve rdar://20990743: Allow the combination of classes/structs and protocols in a type declaration with the original `Any<>` proposal when Swift 3 ships. Your other proposal would enhance it without introducing breaking changes.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.
Why would these cause warnings?

func foo(any: protocol<>)

func foo(any: protocol<Any>)

func foo(any: protocol<Any, ProtocolA>)

func foo(any: protocol<ProtocolA>)

Everything is already fine today.

···

--
Adrian Zubarev
Sent with Airmail

Am 19. Mai 2016 bei 08:55:54, David Waite via swift-evolution (swift-evolution@swift.org) schrieb:

My feedback is that we should narrow what is acceptable for Any as much as possible, because relaxing restrictions in the future won’t break existing code.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.

-DW

On May 19, 2016, at 12:43 AM, Austin Zheng <austinzheng@gmail.com> wrote:

Does anyone want to speak up in favor of 'Any<>'? The more I think about it the more I think 'Any' should just be the single, canonical form.

Austin

On May 18, 2016, at 11:33 PM, Colin Barrett <colin@springsandstruts.com> wrote:

There's no need for this, that's what I was trying to get across. It's (likely) a special case in the grammar right now. If we eliminate Any<>, from the point of view of syntax, both Any and Any<Foo, Bar> are just a built in type and normal application of generic arguments (to a built in type).

-Colin (via thumbs)

On May 19, 2016, at 1:58 AM, Austin Zheng <austinzheng@gmail.com> wrote:

- 'Any<>' should be allowed. You can currently use 'protocol<>' in your code instead of 'Any'.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@swift.org) schrieb:

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

On May 20, 2016, at 9:10 PM, Austin Zheng <austinzheng@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@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: swift-evolution/XXXX-any-as-existential.md at az-protocol-to-any · austinzheng/swift-evolution · GitHub

Best,
Austin

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I've come to the conclusion that the best course of action is to propose this syntax-only change for Swift 3, and then advance the generalized existential proposal after Swift 3 ships. You can ask the reviewers to consider your proposal instead of this one, but given that the Swift 3 release date is in a month I don't think it's likely that anything more substantial than this will be accepted. You are welcome to try, of course.

(response inline, below)

Austin do we really need this 3rd proposal? This makes my original one really a waste of time. I was trying to solve rdar://20990743: Allow the combination of classes/structs and protocols in a type declaration with the original `Any<>` proposal when Swift 3 ships. Your other proposal would enhance it without introducing breaking changes.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.

Why would these cause warnings?

func foo(any: protocol<>)

func foo(any: protocol<Any>)

func foo(any: protocol<Any, ProtocolA>)

func foo(any: protocol<ProtocolA>)

Everything is already fine today.

I agree, adding new warnings is out of the scope of this proposal.

···

On May 19, 2016, at 12:11 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 19. Mai 2016 bei 08:55:54, David Waite via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

My feedback is that we should narrow what is acceptable for Any as much as possible, because relaxing restrictions in the future won’t break existing code.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.

-DW

> On May 19, 2016, at 12:43 AM, Austin Zheng <austinzheng@gmail.com> wrote:
>
> Does anyone want to speak up in favor of 'Any<>'? The more I think about it the more I think 'Any' should just be the single, canonical form.
>
> Austin
>
>
>> On May 18, 2016, at 11:33 PM, Colin Barrett <colin@springsandstruts.com> wrote:
>>
>> There's no need for this, that's what I was trying to get across. It's (likely) a special case in the grammar right now. If we eliminate Any<>, from the point of view of syntax, both Any and Any<Foo, Bar> are just a built in type and normal application of generic arguments (to a built in type).
>>
>> -Colin (via thumbs)
>>
>>> On May 19, 2016, at 1:58 AM, Austin Zheng <austinzheng@gmail.com> wrote:
>>>
>>> - 'Any<>' should be allowed. You can currently use 'protocol<>' in your code instead of 'Any'.
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Forbidding redundant use of protocol<...>/Any<...> would be a great follow-up proposal. Mercifully, there are few interdependencies between the two proposals - you could conceivably propose it even if if Any<...> were rejected, and just have it apply to protocol<...>.

Austin

···

On May 19, 2016, at 12:50 AM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

They can all be interpreted, but:
- they provide multiple ways of expressing the same concept
- the additional uses of Any detract from code clarity
- it is possible (in the absence of an established design) that these syntaxes (particularly Any<Any<ProtocolA>>) might limit our ability to add existential types without either breaking existing code or adding special cases in the parser. I can go into more detail on my reasoning here, but that seems a diversion of this topic to do so.

An example elsewhere in the language of otherwise valid code being rejected because the syntax is redundant:

enum MyError:ErrorType, ErrorType {}

I’m also specifically saying that the *syntax* should warn on the use of Any-within-Any. Code such as:

typealias Foo = Any
typealias Bar = Any<Foo, Sequence>

would be fine.

-DW
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I assume you meant to use Any and not protocol above.

They can all be interpreted, but:
- they provide multiple ways of expressing the same concept
- the additional uses of Any detract from code clarity
- it is possible (in the absence of an established design) that these syntaxes (particularly Any<Any<ProtocolA>>) might limit our ability to add existential types without either breaking existing code or adding special cases in the parser. I can go into more detail on my reasoning here, but that seems a diversion of this topic to do so.

An example elsewhere in the language of otherwise valid code being rejected because the syntax is redundant:

enum MyError:ErrorType, ErrorType {}

I’m also specifically saying that the *syntax* should warn on the use of Any-within-Any. Code such as:

typealias Foo = Any
typealias Bar = Any<Foo, Sequence>

would be fine.

-DW

···

On May 19, 2016, at 1:11 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Austin do we really need this 3rd proposal? This makes my original one really a waste of time. I was trying to solve rdar://20990743: Allow the combination of classes/structs and protocols in a type declaration with the original `Any<>` proposal when Swift 3 ships. Your other proposal would enhance it without introducing breaking changes.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.

Why would these cause warnings?

func foo(any: protocol<>)

func foo(any: protocol<Any>)

func foo(any: protocol<Any, ProtocolA>)

func foo(any: protocol<ProtocolA>)

Everything is already fine today.

Is it really in a month? Who said that? Chris told everyone that until August we can still talk about changes for Swift 3. The evolution repository says Swift 3 will drop late this year not mid. But it’s the core team to decide which proposals they would prefer. This one would be way easier to complete until Swift 3, but it also implies that my and your proposal should be accepted/deffered for Swift 3.x. Otherwise this would be strange just to rename protocol<> to Any<> and not to accept the enhancement of it. :D

···

--
Adrian Zubarev
Sent with Airmail

Am 19. Mai 2016 bei 09:18:43, Austin Zheng (austinzheng@gmail.com) schrieb:

I've come to the conclusion that the best course of action is to propose this syntax-only change for Swift 3, and then advance the generalized existential proposal after Swift 3 ships. You can ask the reviewers to consider your proposal instead of this one, but given that the Swift 3 release date is in a month I don't think it's likely that anything more substantial than this will be accepted. You are welcome to try, of course.

(response inline, below)

On May 19, 2016, at 12:11 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Austin do we really need this 3rd proposal? This makes my original one really a waste of time. I was trying to solve rdar://20990743: Allow the combination of classes/structs and protocols in a type declaration with the original `Any<>` proposal when Swift 3 ships. Your other proposal would enhance it without introducing breaking changes.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.
Why would these cause warnings?

func foo(any: protocol<>)

func foo(any: protocol<Any>)

func foo(any: protocol<Any, ProtocolA>)

func foo(any: protocol<ProtocolA>)

Everything is already fine today.

I agree, adding new warnings is out of the scope of this proposal.

--
Adrian Zubarev
Sent with Airmail

Am 19. Mai 2016 bei 08:55:54, David Waite via swift-evolution (swift-evolution@swift.org) schrieb:

My feedback is that we should narrow what is acceptable for Any as much as possible, because relaxing restrictions in the future won’t break existing code.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.

-DW

On May 19, 2016, at 12:43 AM, Austin Zheng <austinzheng@gmail.com> wrote:

Does anyone want to speak up in favor of 'Any<>'? The more I think about it the more I think 'Any' should just be the single, canonical form.

Austin

On May 18, 2016, at 11:33 PM, Colin Barrett <colin@springsandstruts.com> wrote:

There's no need for this, that's what I was trying to get across. It's (likely) a special case in the grammar right now. If we eliminate Any<>, from the point of view of syntax, both Any and Any<Foo, Bar> are just a built in type and normal application of generic arguments (to a built in type).

-Colin (via thumbs)

On May 19, 2016, at 1:58 AM, Austin Zheng <austinzheng@gmail.com> wrote:

- 'Any<>' should be allowed. You can currently use 'protocol<>' in your code instead of 'Any'.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I assume you meant to use Any and not protocol above.
No, I was wondering why Any<Any, A>> would create a warning whereas protocol<Any, A> does not today.

They can all be interpreted, but:
- they provide multiple ways of expressing the same concept
- the additional uses of Any detract from code clarity
- it is possible (in the absence of an established design) that these syntaxes (particularly Any<Any<ProtocolA>>) might limit our ability to add existential types without either breaking existing code or adding special cases in the parser. I can go into more detail on my reasoning here, but that seems a diversion of this topic to do so.

An example elsewhere in the language of otherwise valid code being rejected because the syntax is redundant:

enum MyError:ErrorType, ErrorType {}

I’m also specifically saying that the *syntax* should warn on the use of Any-within-Any. Code such as:

typealias Foo = Any
typealias Bar = Any<Foo, Sequence>

would be fine.

-DW

And there I have my explanation to this. :)

···

--
Adrian Zubarev
Sent with Airmail

Sorry, you're right about the timeframe. The timeframe I was looking at was for the DP release, not the final release.

What I was thinking of was Joe Groff's comment in the other thread:

"I think any discussion of extending existentials has to be considered out of scope for Swift 3, though, so the Any rename deserves its own proposal."

This proposal is in light of that comment.

Austin

···

On May 19, 2016, at 12:26 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

Is it really in a month? Who said that? Chris told everyone that until August we can still talk about changes for Swift 3. The evolution repository says Swift 3 will drop late this year not mid. But it’s the core team to decide which proposals they would prefer. This one would be way easier to complete until Swift 3, but it also implies that my and your proposal should be accepted/deffered for Swift 3.x. Otherwise this would be strange just to rename protocol<> to Any<> and not to accept the enhancement of it. :D

--
Adrian Zubarev
Sent with Airmail

Am 19. Mai 2016 bei 09:18:43, Austin Zheng (austinzheng@gmail.com <mailto:austinzheng@gmail.com>) schrieb:

I've come to the conclusion that the best course of action is to propose this syntax-only change for Swift 3, and then advance the generalized existential proposal after Swift 3 ships. You can ask the reviewers to consider your proposal instead of this one, but given that the Swift 3 release date is in a month I don't think it's likely that anything more substantial than this will be accepted. You are welcome to try, of course.

(response inline, below)

On May 19, 2016, at 12:11 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Austin do we really need this 3rd proposal? This makes my original one really a waste of time. I was trying to solve rdar://20990743: Allow the combination of classes/structs and protocols in a type declaration with the original `Any<>` proposal when Swift 3 ships. Your other proposal would enhance it without introducing breaking changes.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.

Why would these cause warnings?

func foo(any: protocol<>)

func foo(any: protocol<Any>)

func foo(any: protocol<Any, ProtocolA>)

func foo(any: protocol<ProtocolA>)

Everything is already fine today.

I agree, adding new warnings is out of the scope of this proposal.

--
Adrian Zubarev
Sent with Airmail

Am 19. Mai 2016 bei 08:55:54, David Waite via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

My feedback is that we should narrow what is acceptable for Any as much as possible, because relaxing restrictions in the future won’t break existing code.

To that end, I’d suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.

-DW

> On May 19, 2016, at 12:43 AM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:
>
> Does anyone want to speak up in favor of 'Any<>'? The more I think about it the more I think 'Any' should just be the single, canonical form.
>
> Austin
>
>
>> On May 18, 2016, at 11:33 PM, Colin Barrett <colin@springsandstruts.com <mailto:colin@springsandstruts.com>> wrote:
>>
>> There's no need for this, that's what I was trying to get across. It's (likely) a special case in the grammar right now. If we eliminate Any<>, from the point of view of syntax, both Any and Any<Foo, Bar> are just a built in type and normal application of generic arguments (to a built in type).
>>
>> -Colin (via thumbs)
>>
>>> On May 19, 2016, at 1:58 AM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:
>>>
>>> - 'Any<>' should be allowed. You can currently use 'protocol<>' in your code instead of 'Any'.
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution