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
([email protected]) schrieb:
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]> wrote:
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]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
