[Proposal] Disallow redundant `Any<...>` constructs


(Adrian Zubarev) #1

This is a follow up proposal to SE-0095 which should be considered for Swift 3 if SE-0095 will be accepted.

Here is the formatted draft: https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md

Please provide your feedback in this thread, and don鈥檛 make a race who is making a better proposal on the exact same topic.

If you spot any types or other mistakes I鈥檇 be happy to see you pointing me to them. :wink:

路路路

--
Adrian Zubarev
Sent with Airmail
Disallow redundant Any<...> constructs

Proposal: SE-NNNN
Author: Adrian Zubarev
Status: Awaiting review
Review manager: TBD
Introduction

This is a follow up proposal to SE鈥0095, if it will be accepted for Swift 3. The current concept of Any<...> introduced in SE鈥0095 will allow creation of redundant types like Any<A> == A. I propose to disallow such redundancy in Swift 3 to prevent breaking changes in a future version of Swift.

Swift-evolution thread: [Proposal] Disallow redundant Any<...> constructs

Motivation

If SE鈥0095 will be accepted there will be future proposals to enhance its capabilities. Two of these will be Any-type requirement (where type could be class, struct or enum) and Class requirement. Without any restrictions these will introduce more redundancy.

As said before it is possible to create redundant types like Any<A> == A or endless shadowed redundant nesting:

typealias A_1 = Any<A>
typealias A_2 = Any<A_1>
typealias A_3 = Any<A_2>
/* and so on */
This proposal should ban redundancy right from the beginning. If there might be any desire to relax a few things, it won鈥檛 introduce any breaking changes for Any<...> existential.

Proposed solution

If empty Any<> won鈥檛 be disallowed in SE鈥0095, we should disallow nesting empty Any<> inside of Any<...>.

Disallow nesting Any (type refers to current typealias Any = protocol<>) inside of Any<...>.

Disallow Any<...> containing a single Type like Any<Type>.

The first three rules will ban constructs like Any<Any<>, Type> or Any<Any, Type> and force the developer to use Type instead.

Disallow nesting a single Any<...> inside another Any<...>.
e.g. Any<Any<FirstType, SecondType>>
Disallow same type usage like Any<A, A> or Any<A, B, A> and force the developer to use A or Any<A, B> if A and B are distinct.

Disallow forming redundant types when the provided constraints are not independent.

// Right now `type` can only be `protocol` but in the future Any<...>
// could also allow `class`, `struct` and `enum`.
// In this example `B` and `C` are distinct.
type A: B, C {}
聽聽聽聽聽
// all following types are equivalent to `A`
Any<A, Any<B, C>>
Any<Any<A, B>, C>
Any<Any<A, C>, B>
Any<A, B, C>
Any<A, B>
Any<A, C>
If all contraints form a known Type provide a Fix-it error depending on the current context. If there is more than one Type, provide all alternatives to the developer.

Using Any<...> in a generic context might not produce a Fix-it error:

protocol A {}
protocol B {}
protocol C: A, B {}
聽聽聽聽聽聽聽聽聽
// there is no need for `Fix-it` in such a context
func foo<T: Any<A, B>>(value: T) {}
Impact on existing code

These changes will break existing code. Projects abusing Any<...> to create redundant types should be reconsidered of usings the equivalent Type the compiler would infer. One would be forced to use A instead of Any<A> for example. A Fix-it error message can help the developer to migrate his project.

Alternatives considered

Leave redundancy as-is for Swift 3 and live with it.
Deprecate redundancy in a future version of Swift, which will introduce breaking changes.


(Austin Zheng) #2

I think you should submit this for review, but I also think you should take
the part of your older proposal to add class support to Any<...> and submit
it as a separate proposal. (I mean, the part where you can define things
like "Any<UIViewController, Protocol>" or "Any<class, Protocol>".)

Yes, it is additive, but even getting that feature into Swift 3 would be an
enormous benefit if it can be implemented easily. And the core team is
probably better positioned than anyone else to determine whether that's
true.

Austin

路路路

On Fri, May 20, 2016 at 2:39 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:

This is a follow up proposal to SE-0095
<https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md> which
should be considered for Swift 3 if SE-0095 will be accepted.

Here is the formatted draft:
https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md

Please provide your feedback in this thread, and don鈥檛 make a race who is
making a better proposal on the exact same topic.

If you spot any types or other mistakes I鈥檇 be happy to see you pointing
me to them. :wink:

--
Adrian Zubarev
Sent with Airmail

Disallow redundant Any<...> constructs

聽聽聽- Proposal: SE-NNNN
聽聽聽<https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
聽聽聽- Author: Adrian Zubarev <https://github.com/DevAndArtist>
聽聽聽- Status: Awaiting review <#m_3447501318802576264_rationale>
聽聽聽- Review manager: TBD

Introduction

This is a follow up proposal to SE鈥0095
<https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md>,
if it will be accepted for Swift 3. The current concept of Any<...>
introduced in SE鈥0095 will allow creation of redundant types like Any<A>
== A. I propose to disallow such redundancy in Swift 3 to prevent
breaking changes in a future version of Swift.

Swift-evolution thread: [Proposal] Disallow redundant Any<...> constructs
Motivation

If SE鈥0095 will be accepted there will be future proposals to enhance its
capabilities. Two of these will be *Any-type requirement* (where *type*
could be class, struct or enum) and *Class requirement*. Without any
restrictions these will introduce more redundancy.

As said before it is possible to create redundant types like Any<A> == A
or endless shadowed redundant nesting:

typealias A_1 = Any<A>
typealias A_2 = Any<A_1>
typealias A_3 = Any<A_2>
/* and so on */

This proposal should ban redundancy right from the beginning. If there
might be any desire to relax a few things, it won鈥檛 introduce any breaking
changes for Any<...> existential.
Proposed solution

聽聽聽1.

聽聽聽If empty Any<> won鈥檛 be disallowed in SE鈥0095, we should disallow
聽聽聽nesting empty Any<> inside of Any<...>.
聽聽聽2.

聽聽聽Disallow nesting Any (type refers to current typealias Any = protocol<>)
聽聽聽inside of Any<...>.
聽聽聽3.

聽聽聽Disallow Any<...> containing a single Type like Any<Type>.

聽聽聽The first three rules will ban constructs like Any<Any<>, Type> or Any<Any,
聽聽聽> and force the developer to use Type instead.
聽聽聽4. Disallow nesting a single Any<...> inside another Any<...>.
聽聽聽聽聽聽- e.g. Any<Any<FirstType, SecondType>>
聽聽聽5.

聽聽聽Disallow same type usage like Any<A, A> or Any<A, B, A> and force the
聽聽聽developer to use A or Any<A, B> if A and B are distinct.
聽聽聽6.

聽聽聽Disallow forming redundant types when the provided constraints are not
聽聽聽independent.

聽聽聽// Right now `type` can only be `protocol` but in the future Any<...>
聽聽聽// could also allow `class`, `struct` and `enum`.
聽聽聽// In this example `B` and `C` are distinct.
聽聽聽type A: B, C {}

聽聽聽// all following types are equivalent to `A`
聽聽聽Any<A, Any<B, C>>
聽聽聽Any<Any<A, B>, C>
聽聽聽Any<Any<A, C>, B>
聽聽聽Any<A, B, C>
聽聽聽Any<A, B>
聽聽聽Any<A, C>

聽聽聽-

聽聽聽聽聽聽If all contraints form a known Type provide a Fix-it error
聽聽聽聽聽聽depending on the current context. If there is more than one Type,
聽聽聽聽聽聽provide all alternatives to the developer.
聽聽聽聽聽聽-

聽聽聽聽聽聽Using Any<...> in a generic context might not produce a Fix-it
聽聽聽聽聽聽error:

聽聽聽聽聽聽protocol A {}
聽聽聽聽聽聽protocol B {}
聽聽聽聽聽聽protocol C: A, B {}

聽聽聽聽聽聽// there is no need for `Fix-it` in such a context
聽聽聽聽聽聽func foo<T: Any<A, B>>(value: T) {}

Impact on existing code

These changes will break existing code. Projects abusing Any<...> to
create redundant types should be reconsidered of usings the equivalent
Type the compiler would infer. One would be forced to use A instead of
Any<A> for example. A Fix-it error message can help the developer to
migrate his project.
Alternatives considered

聽聽聽- Leave redundancy as-is for Swift 3 and live with it.
聽聽聽- Deprecate redundancy in a future version of Swift, which will
聽聽聽introduce breaking changes.

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


(Adrian Zubarev) #3

What I meant here is, that the example should produce an error because it is basically `Any<Any<Any<鈥>>>` which should be banned. It depends on the context. Using typealias in general can be allowed but it depends how you will use and nest it.

This example is valid:

protocol A {} protocol B {} protocol C {}

typealias AB = Any<A, B>
typealias ABC = Any<AB, C>

If we ban `Any<Any<...>>` one should not abuse `typealias` to achieve that, even if its useless. I鈥檓 not sure how hard that would be implement that restriction.

The example you was pointing at wouldn鈥檛 work anyway because the rule #3 and rule #4 should raise an error. Thats how I see it.

If I鈥檓 not correct please provide an example that makes more sense. :slight_smile:

路路路

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 16:44:35, Matthew Johnson (matthew@anandabits.com) schrieb:

Sent from my iPad

On May 20, 2016, at 4:39 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

This is a follow up proposal to SE-0095 which should be considered for Swift 3 if SE-0095 will be accepted.

Here is the formatted draft: https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md

Please provide your feedback in this thread, and don鈥檛 make a race who is making a better proposal on the exact same topic.

If you spot any types or other mistakes I鈥檇 be happy to see you pointing me to them. :wink:

--
Adrian Zubarev
Sent with Airmail
Disallow redundant Any<...> constructs

Proposal: SE-NNNN
Author: Adrian Zubarev
Status: Awaiting review
Review manager: TBD
Introduction

This is a follow up proposal to SE鈥0095, if it will be accepted for Swift 3. The current concept of Any<...> introduced in SE鈥0095 will allow creation of redundant types like Any<A> == A. I propose to disallow such redundancy in Swift 3 to prevent breaking changes in a future version of Swift.

Swift-evolution thread: [Proposal] Disallow redundant Any<...> constructs

Motivation

If SE鈥0095 will be accepted there will be future proposals to enhance its capabilities. Two of these will be Any-type requirement (where type could be class, struct or enum) and Class requirement. Without any restrictions these will introduce more redundancy.

As said before it is possible to create redundant types like Any<A> == A or endless shadowed redundant nesting:

typealias A_1 = Any<A>
typealias A_2 = Any<A_1>
typealias A_3 = Any<A_2>
/* and so on */

This proposal should ban redundancy right from the beginning. If there might be any desire to relax a few things, it won鈥檛 introduce any breaking changes for Any<...> existential.

Why do you think having multiple typealiases for the same type is a problem? The whole point of typealias is to alias the name of the type.

Proposed solution

If empty Any<> won鈥檛 be disallowed in SE鈥0095, we should disallow nesting empty Any<> inside of Any<...>.

Disallow nesting Any (type refers to current typealias Any = protocol<>) inside of Any<...>.

Disallow Any<...> containing a single Type like Any<Type>.

The first three rules will ban constructs like Any<Any<>, Type> or Any<Any, Type> and force the developer to use Type instead.

Disallow nesting a single Any<...> inside another Any<...>.
e.g. Any<Any<FirstType, SecondType>>
Disallow same type usage like Any<A, A> or Any<A, B, A> and force the developer to use A or Any<A, B> if A and B are distinct.

Disallow forming redundant types when the provided constraints are not independent.

// Right now `type` can only be `protocol` but in the future Any<...>
// could also allow `class`, `struct` and `enum`.
// In this example `B` and `C` are distinct.
type A: B, C {}
聽聽聽聽聽聽
// all following types are equivalent to `A`
Any<A, Any<B, C>>
Any<Any<A, B>, C>
Any<Any<A, C>, B>
Any<A, B, C>
Any<A, B>
Any<A, C>

If all contraints form a known Type provide a Fix-it error depending on the current context. If there is more than one Type, provide all alternatives to the developer.

Using Any<...> in a generic context might not produce a Fix-it error:

protocol A {}
protocol B {}
protocol C: A, B {}
聽聽聽聽聽聽聽聽聽聽
// there is no need for `Fix-it` in such a context
func foo<T: Any<A, B>>(value: T) {}

Impact on existing code

These changes will break existing code. Projects abusing Any<...> to create redundant types should be reconsidered of usings the equivalent Type the compiler would infer. One would be forced to use A instead of Any<A> for example. A Fix-it error message can help the developer to migrate his project.

Alternatives considered

Leave redundancy as-is for Swift 3 and live with it.
Deprecate redundancy in a future version of Swift, which will introduce breaking changes.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #4

What's the behavior if you have something like this:

struct Foo<T, U> {
聽聽聽聽func foo(bar: Any<T, U>) { ... }
}
let f = Foo<A, A>

鈥?

We already discussed this topic. You cannot use names dependent on generic arguments in `Any`. This is the same as with `protocol` today. This is because many times it would be invalid (if T was String and U was Int in your example).

The closest you could get is if the compiler used the constraints on T and U to synthesize a similarly constrained Any. However, I don鈥檛 see why you would do that and believe it would be more confusing. If you want an existential with the same constraints as your generic arguments we should do that using the typealias mechanism discussed in the generalized existential proposal.

typealias Foo = Any<鈥onstraints鈥>
typealias Bar = Any<鈥onstraints鈥>

struct Foo<T: Foo, U, Bar> {
聽聽聽聽func foo(bar: Any<Foo, Bar>) { ... }
}

Thorsten鈥檚 idea to lowercase `Any` to `any` is a very good one. This makes it clear that `Any` does not behave like user-defined generic types (where it *is* possible to use generic arguments as long as they are suitably constrained).

More generally, my fear is that being *too* restrictive about banning redundant types could get you into a situation through generic metaprogramming where you might *want* that argument to coalesce to just "A", but if the redundancy check is implemented a certain way, you've just prevented a perhaps legitimate usage with no easy workaround.

I'm inclined to just say: minimize redundant types automatically and if a user wants to write something redundant, that's fine鈥攕o a variable declared with type `Any<A, A>` would actually be of type `A`. You might be able to avoid this if you only check the *literal* type or type parameter name going into the Any<>, but I'm not sure how much difficulty that is on the type checking side, and then you'd only catch some of the cases and you'd still have to be able to minimize.

Yes, I have made the same argument. We should not be arbitrarily banning valid, well-defined syntactic constructs for stylistic reasons. They should just be simplified by the compiler such that all syntactic forms are equivalent.

On the other hand, as you note, if there are implementation reasons for introducing restrictions that is an entirely separate conversation. If we cannot simplify conceptually equivalent syntactic forms such that they have identical behavior that would be a valid reason to consider syntactic restrictions.

路路路

On May 20, 2016, at 10:18 AM, Tony Allevato via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, May 20, 2016 at 7:53 AM Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
What I meant here is, that the example should produce an error because it is basically `Any<Any<Any<鈥>>>` which should be banned. It depends on the context. Using typealias in general can be allowed but it depends how you will use and nest it.

This example is valid:

protocol A {} protocol B {} protocol C {}

typealias AB = Any<A, B>
typealias ABC = Any<AB, C>

If we ban `Any<Any<...>>` one should not abuse `typealias` to achieve that, even if its useless. I鈥檓 not sure how hard that would be implement that restriction.

The example you was pointing at wouldn鈥檛 work anyway because the rule #3 and rule #4 should raise an error. Thats how I see it.

If I鈥檓 not correct please provide an example that makes more sense. :slight_smile:

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 16:44:35, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

Sent from my iPad

On May 20, 2016, at 4:39 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This is a follow up proposal to SE-0095 <https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md> which should be considered for Swift 3 if SE-0095 will be accepted.

Here is the formatted draft: https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md

Please provide your feedback in this thread, and don鈥檛 make a race who is making a better proposal on the exact same topic.

If you spot any types or other mistakes I鈥檇 be happy to see you pointing me to them. :wink:

--
Adrian Zubarev
Sent with Airmail
Disallow redundant Any<...> constructs

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author: Adrian Zubarev <https://github.com/DevAndArtist>
Status: Awaiting review <x-msg://300/#m_-6273636555714890771_rationale>
Review manager: TBD
Introduction

This is a follow up proposal to SE鈥0095 <https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md>, if it will be accepted for Swift 3. The current concept of Any<...> introduced in SE鈥0095 will allow creation of redundant types like Any<A> == A. I propose to disallow such redundancy in Swift 3 to prevent breaking changes in a future version of Swift.

Swift-evolution thread: [Proposal] Disallow redundant Any<...> constructs <>
Motivation

If SE鈥0095 will be accepted there will be future proposals to enhance its capabilities. Two of these will be Any-type requirement (where type could be class, struct or enum) and Class requirement. Without any restrictions these will introduce more redundancy.

As said before it is possible to create redundant types like Any<A> == A or endless shadowed redundant nesting:

typealias A_1 = Any<A>
typealias A_2 = Any<A_1>
typealias A_3 = Any<A_2>
/* and so on */

This proposal should ban redundancy right from the beginning. If there might be any desire to relax a few things, it won鈥檛 introduce any breaking changes for Any<...> existential.

Why do you think having multiple typealiases for the same type is a problem? The whole point of typealias is to alias the name of the type.

Proposed solution

If empty Any<> won鈥檛 be disallowed in SE鈥0095, we should disallow nesting empty Any<> inside of Any<...>.

Disallow nesting Any (type refers to current typealias Any = protocol<>) inside of Any<...>.

Disallow Any<...> containing a single Type like Any<Type>.

The first three rules will ban constructs like Any<Any<>, Type> or Any<Any, Type> and force the developer to use Type instead.

Disallow nesting a single Any<...> inside another Any<...>.
e.g. Any<Any<FirstType, SecondType>>
Disallow same type usage like Any<A, A> or Any<A, B, A> and force the developer to use A or Any<A, B> if A and B are distinct.

Disallow forming redundant types when the provided constraints are not independent.

// Right now `type` can only be `protocol` but in the future Any<...>
// could also allow `class`, `struct` and `enum`.
// In this example `B` and `C` are distinct.
type A: B, C {}
聽聽聽聽聽聽
// all following types are equivalent to `A`
Any<A, Any<B, C>>
Any<Any<A, B>, C>
Any<Any<A, C>, B>
Any<A, B, C>
Any<A, B>
Any<A, C>

If all contraints form a known Type provide a Fix-it error depending on the current context. If there is more than one Type, provide all alternatives to the developer.

Using Any<...> in a generic context might not produce a Fix-it error:

protocol A {}
protocol B {}
protocol C: A, B {}
聽聽聽聽聽聽聽聽聽聽
// there is no need for `Fix-it` in such a context
func foo<T: Any<A, B>>(value: T) {}

Impact on existing code

These changes will break existing code. Projects abusing Any<...> to create redundant types should be reconsidered of usings the equivalent Type the compiler would infer. One would be forced to use A instead of Any<A> for example. A Fix-it error message can help the developer to migrate his project.

Alternatives considered

Leave redundancy as-is for Swift 3 and live with it.
Deprecate redundancy in a future version of Swift, which will introduce breaking changes.
_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #5

I think you should submit this for review, but I also think you should take the part of your older proposal to add class support to Any<...> and submit it as a separate proposal. (I mean, the part where you can define things like "Any<UIViewController, Protocol>" or "Any<class, Protocol>".)

Yes, it is additive, but even getting that feature into Swift 3 would be an enormous benefit if it can be implemented easily. And the core team is probably better positioned than anyone else to determine whether that's true.

Austin, what is your thought on switching to `any` rather than `Any` since it does not behave like a user-defined generic type? The convention is for types to be uppercase and keywords to be lowercase. This falls more into the category of a keyword and has its own behavior distinct from the behavior of all generic types. Making it stand out syntactically will help to make that clear.

路路路

On May 20, 2016, at 2:00 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

Austin

On Fri, May 20, 2016 at 2:39 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This is a follow up proposal to SE-0095 <https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md> which should be considered for Swift 3 if SE-0095 will be accepted.

Here is the formatted draft: https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md

Please provide your feedback in this thread, and don鈥檛 make a race who is making a better proposal on the exact same topic.

If you spot any types or other mistakes I鈥檇 be happy to see you pointing me to them. :wink:

--
Adrian Zubarev
Sent with Airmail

Disallow redundant Any<...> constructs

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author: Adrian Zubarev <https://github.com/DevAndArtist>
Status: Awaiting review <x-msg://378/#m_3447501318802576264_rationale>
Review manager: TBD
Introduction

This is a follow up proposal to SE鈥0095 <https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md>, if it will be accepted for Swift 3. The current concept of Any<...> introduced in SE鈥0095 will allow creation of redundant types like Any<A> == A. I propose to disallow such redundancy in Swift 3 to prevent breaking changes in a future version of Swift.

Swift-evolution thread: [Proposal] Disallow redundant Any<...> constructs <>
Motivation

If SE鈥0095 will be accepted there will be future proposals to enhance its capabilities. Two of these will be Any-type requirement (where type could be class, struct or enum) and Class requirement. Without any restrictions these will introduce more redundancy.

As said before it is possible to create redundant types like Any<A> == A or endless shadowed redundant nesting:

typealias A_1 = Any<A>
typealias A_2 = Any<A_1>
typealias A_3 = Any<A_2>
/* and so on */
This proposal should ban redundancy right from the beginning. If there might be any desire to relax a few things, it won鈥檛 introduce any breaking changes for Any<...> existential.

Proposed solution

If empty Any<> won鈥檛 be disallowed in SE鈥0095, we should disallow nesting empty Any<> inside of Any<...>.

Disallow nesting Any (type refers to current typealias Any = protocol<>) inside of Any<...>.

Disallow Any<...> containing a single Type like Any<Type>.

The first three rules will ban constructs like Any<Any<>, Type> or Any<Any, Type> and force the developer to use Type instead.

Disallow nesting a single Any<...> inside another Any<...>.
e.g. Any<Any<FirstType, SecondType>>
Disallow same type usage like Any<A, A> or Any<A, B, A> and force the developer to use A or Any<A, B> if A and B are distinct.

Disallow forming redundant types when the provided constraints are not independent.

// Right now `type` can only be `protocol` but in the future Any<...>
// could also allow `class`, `struct` and `enum`.
// In this example `B` and `C` are distinct.
type A: B, C {}
聽聽聽聽聽
// all following types are equivalent to `A`
Any<A, Any<B, C>>
Any<Any<A, B>, C>
Any<Any<A, C>, B>
Any<A, B, C>
Any<A, B>
Any<A, C>
If all contraints form a known Type provide a Fix-it error depending on the current context. If there is more than one Type, provide all alternatives to the developer.

Using Any<...> in a generic context might not produce a Fix-it error:

protocol A {}
protocol B {}
protocol C: A, B {}
聽聽聽聽聽聽聽聽聽
// there is no need for `Fix-it` in such a context
func foo<T: Any<A, B>>(value: T) {}
Impact on existing code

These changes will break existing code. Projects abusing Any<...> to create redundant types should be reconsidered of usings the equivalent Type the compiler would infer. One would be forced to use A instead of Any<A> for example. A Fix-it error message can help the developer to migrate his project.

Alternatives considered

Leave redundancy as-is for Swift 3 and live with it.
Deprecate redundancy in a future version of Swift, which will introduce breaking changes.

_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tony Allevato) #6

What's the behavior if you have something like this:

struct Foo<T, U> {
聽聽聽聽func foo(bar: Any<T, U>) { ... }
}
let f = Foo<A, A>

...?

More generally, my fear is that being *too* restrictive about banning
redundant types could get you into a situation through generic
metaprogramming where you might *want* that argument to coalesce to just
"A", but if the redundancy check is implemented a certain way, you've just
prevented a perhaps legitimate usage with no easy workaround.

I'm inclined to just say: minimize redundant types automatically and if a
user wants to write something redundant, that's fine鈥攕o a variable declared
with type `Any<A, A>` would actually be of type `A`. You might be able to
avoid this if you only check the *literal* type or type parameter name
going into the Any<>, but I'm not sure how much difficulty that is on the
type checking side, and then you'd only catch some of the cases and you'd
still have to be able to minimize.

路路路

On Fri, May 20, 2016 at 7:53 AM Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:

What I meant here is, that the example should produce an error because it
is basically `Any<Any<Any<鈥>>>` which should be banned. It depends on the
context. Using typealias in general can be allowed but it depends how you
will use and nest it.

This example is valid:

protocol A {} protocol B {} protocol C {}

typealias AB = Any<A, B>
typealias ABC = Any<AB, C>

If we ban `Any<Any<...>>` one should not abuse `typealias` to achieve
that, even if its useless. I鈥檓 not sure how hard that would be implement
that restriction.

The example you was pointing at wouldn鈥檛 work anyway because the rule #3
and rule #4 should raise an error. Thats how I see it.

If I鈥檓 not correct please provide an example that makes more sense. :slight_smile:

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 16:44:35, Matthew Johnson (matthew@anandabits.com)
schrieb:

Sent from my iPad

On May 20, 2016, at 4:39 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

This is a follow up proposal to SE-0095
<https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md> which
should be considered for Swift 3 if SE-0095 will be accepted.

Here is the formatted draft:
https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md

Please provide your feedback in this thread, and don鈥檛 make a race who is
making a better proposal on the exact same topic.

If you spot any types or other mistakes I鈥檇 be happy to see you pointing
me to them. :wink:

--
Adrian Zubarev
Sent with Airmail
Disallow redundant Any<...> constructs

聽聽聽- Proposal: SE-NNNN
聽聽聽<https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
聽聽聽- Author: Adrian Zubarev <https://github.com/DevAndArtist>
聽聽聽- Status: Awaiting review <#m_-6273636555714890771_rationale>
聽聽聽- Review manager: TBD

Introduction

This is a follow up proposal to SE鈥0095
<https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md>,
if it will be accepted for Swift 3. The current concept of Any<...>
introduced in SE鈥0095 will allow creation of redundant types like Any<A>
== A. I propose to disallow such redundancy in Swift 3 to prevent
breaking changes in a future version of Swift.

Swift-evolution thread: [Proposal] Disallow redundant Any<...> constructs
Motivation

If SE鈥0095 will be accepted there will be future proposals to enhance its
capabilities. Two of these will be *Any-type requirement* (where *type*
could be class, struct or enum) and *Class requirement*. Without any
restrictions these will introduce more redundancy.

As said before it is possible to create redundant types like Any<A> == A
or endless shadowed redundant nesting:

typealias A_1 = Any<A>
typealias A_2 = Any<A_1>
typealias A_3 = Any<A_2>
/* and so on */

This proposal should ban redundancy right from the beginning. If there
might be any desire to relax a few things, it won鈥檛 introduce any breaking
changes for Any<...> existential.

Why do you think having multiple typealiases for the same type is a
problem? The whole point of typealias is to *alias* the name of the
type.

Proposed solution

聽聽聽1.

聽聽聽If empty Any<> won鈥檛 be disallowed in SE鈥0095, we should disallow
聽聽聽nesting empty Any<> inside of Any<...>.
聽聽聽2.

聽聽聽Disallow nesting Any (type refers to current typealias Any = protocol<>)
聽聽聽inside of Any<...>.
聽聽聽3.

聽聽聽Disallow Any<...> containing a single Type like Any<Type>.

聽聽聽The first three rules will ban constructs like Any<Any<>, Type> or Any<Any,
聽聽聽> and force the developer to use Type instead.
聽聽聽4. Disallow nesting a single Any<...> inside another Any<...>.
聽聽聽聽聽聽- e.g. Any<Any<FirstType, SecondType>>
聽聽聽5.

聽聽聽Disallow same type usage like Any<A, A> or Any<A, B, A> and force the
聽聽聽developer to use A or Any<A, B> if A and B are distinct.
聽聽聽6.

聽聽聽Disallow forming redundant types when the provided constraints are not
聽聽聽independent.

聽聽聽// Right now `type` can only be `protocol` but in the future Any<...>
聽聽聽// could also allow `class`, `struct` and `enum`.
聽聽聽// In this example `B` and `C` are distinct.
聽聽聽type A: B, C {}

聽聽聽// all following types are equivalent to `A`
聽聽聽Any<A, Any<B, C>>
聽聽聽Any<Any<A, B>, C>
聽聽聽Any<Any<A, C>, B>
聽聽聽Any<A, B, C>
聽聽聽Any<A, B>
聽聽聽Any<A, C>

聽聽聽-

聽聽聽聽聽聽If all contraints form a known Type provide a Fix-it error
聽聽聽聽聽聽depending on the current context. If there is more than one Type,
聽聽聽聽聽聽provide all alternatives to the developer.
聽聽聽聽聽聽-

聽聽聽聽聽聽Using Any<...> in a generic context might not produce a Fix-it
聽聽聽聽聽聽error:

聽聽聽聽聽聽protocol A {}
聽聽聽聽聽聽protocol B {}
聽聽聽聽聽聽protocol C: A, B {}

聽聽聽聽聽聽// there is no need for `Fix-it` in such a context
聽聽聽聽聽聽func foo<T: Any<A, B>>(value: T) {}

Impact on existing code

These changes will break existing code. Projects abusing Any<...> to
create redundant types should be reconsidered of usings the equivalent
Type the compiler would infer. One would be forced to use A instead of
Any<A> for example. A Fix-it error message can help the developer to
migrate his project.
Alternatives considered

聽聽聽- Leave redundancy as-is for Swift 3 and live with it.
聽聽聽- Deprecate redundancy in a future version of Swift, which will
聽聽聽introduce breaking changes.

_______________________________________________
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


(Adrian Zubarev) #7

I don't understand what you mean. I definitely think your 'typealias ABC = Any<AB, C>' should be valid.
I said typealias ABC = Any<AB, C> is valid.

Where

typealias AliasA = Any<A>

is not and furthermore

typealias AliasAA = Any<AliasA>

should also not be valid because Any<Any<A>> shouldn鈥檛 be valid.

IMO the rules around banning nested any are unnecessary complexity. The constructs have a well defined meaning. The argument to ban them is purely around limiting allowable syntactic style. People are very unlikely to actually use this nesting except through the abstraction of a typealias which is a very valid use case. The complexity of the rules does not appear to provide any tangible benefit.

Which rule(s) do you refer to exactly?

路路路

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:12:40, Matthew Johnson (matthew@anandabits.com) schrieb:


(Adrian Zubarev) #8

I think you should submit this for review, but I also think you should take the part of your older proposal to add class support to Any<...> and submit it as a separate proposal. (I mean, the part where you can define things like "Any<UIViewController, Protocol>" or "Any<class, Protocol>".)

I鈥檇 like to separate these into different proposals like already suggested on github. Not sure about `Any<class, Protocol>`. I鈥檓 not even sure what we鈥檒l get in Swift 3 now from the Generics Manifesto. I鈥檒l submit `Any<UIView, Protocol>` proposal as soon as I can find some time to rewrite it.

路路路

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 21:00:38, Austin Zheng (austinzheng@gmail.com) schrieb:


(Matthew Johnson) #9

I don't understand what you mean. I definitely think your 'typealias ABC = Any<AB, C>' should be valid.

I said typealias ABC = Any<AB, C> is valid.

Where

typealias AliasA = Any<A>

is not and furthermore

typealias AliasAA = Any<AliasA>

should also not be valid because Any<Any<A>> shouldn鈥檛 be valid.

IMO the rules around banning nested any are unnecessary complexity. The constructs have a well defined meaning. The argument to ban them is purely around limiting allowable syntactic style. People are very unlikely to actually use this nesting except through the abstraction of a typealias which is a very valid use case. The complexity of the rules does not appear to provide any tangible benefit.

Which rule(s) do you refer to exactly?

Any rules that ban syntactic constructs which have a well defined meaning on purely stylistic grounds. Those introduce unnecessary complexity for little, if any benefit. As Tony points out, it is possible that such bans would have unintended consequences and ban useful constructs. It is not worth the effort to try to ensure they don鈥檛 have unintended consequences.

We rely on people to do sensible things stylistically all the time (Swift does not enforce code layout like some languages do). I don鈥檛 see why `Any` should be different.

路路路

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

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:12:40, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

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


(Austin Zheng) #10

I actually like "any<P1, P2>". It does provide that very distinctive visual
signal that any<> is not a generic type, and that 'any' is not itself a
type, but rather a special keyword for constructing an existential:

Array<Int> // a generic type, Array, containing integers
any<P1, P2> // a protocol composition of two protocols

In this case, would we want to support "any<>" in addition to Any? The
parsing issues should go away, since these are two different identifiers.

Austin

路路路

On Fri, May 20, 2016 at 12:04 PM, Matthew Johnson <matthew@anandabits.com> wrote:

On May 20, 2016, at 2:00 PM, Austin Zheng via swift-evolution < > swift-evolution@swift.org> wrote:

I think you should submit this for review, but I also think you should
take the part of your older proposal to add class support to Any<...> and
submit it as a separate proposal. (I mean, the part where you can define
things like "Any<UIViewController, Protocol>" or "Any<class, Protocol>".)

Yes, it is additive, but even getting that feature into Swift 3 would be
an enormous benefit if it can be implemented easily. And the core team is
probably better positioned than anyone else to determine whether that's
true.

Austin, what is your thought on switching to `any` rather than `Any` since
it does not behave like a user-defined generic type? The convention is for
types to be uppercase and keywords to be lowercase. This falls more into
the category of a keyword and has its own behavior distinct from the
behavior of all generic types. Making it stand out syntactically will help
to make that clear.

Austin

On Fri, May 20, 2016 at 2:39 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

This is a follow up proposal to SE-0095
<https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md> which
should be considered for Swift 3 if SE-0095 will be accepted.

Here is the formatted draft:
https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md

Please provide your feedback in this thread, and don鈥檛 make a race who is
making a better proposal on the exact same topic.

If you spot any types or other mistakes I鈥檇 be happy to see you pointing
me to them. :wink:

--
Adrian Zubarev
Sent with Airmail

Disallow redundant Any<...> constructs

聽聽聽- Proposal: SE-NNNN
聽聽聽<https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
聽聽聽- Author: Adrian Zubarev <https://github.com/DevAndArtist>
聽聽聽- Status: Awaiting review
聽聽聽- Review manager: TBD

Introduction

This is a follow up proposal to SE鈥0095
<https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md>,
if it will be accepted for Swift 3. The current concept of Any<...>
introduced in SE鈥0095 will allow creation of redundant types like Any<A>
== A. I propose to disallow such redundancy in Swift 3 to prevent
breaking changes in a future version of Swift.

Swift-evolution thread: [Proposal] Disallow redundant Any<...> constructs
Motivation

If SE鈥0095 will be accepted there will be future proposals to enhance its
capabilities. Two of these will be *Any-type requirement* (where *type*
could be class, struct or enum) and *Class requirement*. Without any
restrictions these will introduce more redundancy.

As said before it is possible to create redundant types like Any<A> == A
or endless shadowed redundant nesting:

typealias A_1 = Any<A>
typealias A_2 = Any<A_1>
typealias A_3 = Any<A_2>
/* and so on */

This proposal should ban redundancy right from the beginning. If there
might be any desire to relax a few things, it won鈥檛 introduce any breaking
changes for Any<...> existential.
Proposed solution

聽聽聽1.

聽聽聽If empty Any<> won鈥檛 be disallowed in SE鈥0095, we should disallow
聽聽聽nesting empty Any<> inside of Any<...>.
聽聽聽2.

聽聽聽Disallow nesting Any (type refers to current typealias Any =
聽聽聽protocol<>) inside of Any<...>.
聽聽聽3.

聽聽聽Disallow Any<...> containing a single Type like Any<Type>.

聽聽聽The first three rules will ban constructs like Any<Any<>, Type> or Any<Any,
聽聽聽> and force the developer to use Type instead.
聽聽聽4. Disallow nesting a single Any<...> inside another Any<...>.
聽聽聽聽聽聽- e.g. Any<Any<FirstType, SecondType>>
聽聽聽5.

聽聽聽Disallow same type usage like Any<A, A> or Any<A, B, A> and force the
聽聽聽developer to use A or Any<A, B> if A and B are distinct.
聽聽聽6.

聽聽聽Disallow forming redundant types when the provided constraints are
聽聽聽not independent.

聽聽聽// Right now `type` can only be `protocol` but in the future Any<...>
聽聽聽// could also allow `class`, `struct` and `enum`.
聽聽聽// In this example `B` and `C` are distinct.
聽聽聽type A: B, C {}

聽聽聽// all following types are equivalent to `A`
聽聽聽Any<A, Any<B, C>>
聽聽聽Any<Any<A, B>, C>
聽聽聽Any<Any<A, C>, B>
聽聽聽Any<A, B, C>
聽聽聽Any<A, B>
聽聽聽Any<A, C>

聽聽聽-

聽聽聽聽聽聽If all contraints form a known Type provide a Fix-it error
聽聽聽聽聽聽depending on the current context. If there is more than one Type,
聽聽聽聽聽聽provide all alternatives to the developer.
聽聽聽聽聽聽-

聽聽聽聽聽聽Using Any<...> in a generic context might not produce a Fix-it
聽聽聽聽聽聽error:

聽聽聽聽聽聽protocol A {}
聽聽聽聽聽聽protocol B {}
聽聽聽聽聽聽protocol C: A, B {}

聽聽聽聽聽聽// there is no need for `Fix-it` in such a context
聽聽聽聽聽聽func foo<T: Any<A, B>>(value: T) {}

Impact on existing code

These changes will break existing code. Projects abusing Any<...> to
create redundant types should be reconsidered of usings the equivalent
Type the compiler would infer. One would be forced to use A instead of
Any<A> for example. A Fix-it error message can help the developer to
migrate his project.
Alternatives considered

聽聽聽- Leave redundancy as-is for Swift 3 and live with it.
聽聽聽- Deprecate redundancy in a future version of Swift, which will
聽聽聽introduce breaking changes.

_______________________________________________
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


(Matthew Johnson) #11

I actually like "any<P1, P2>". It does provide that very distinctive visual signal that any<> is not a generic type, and that 'any' is not itself a type, but rather a special keyword for constructing an existential:

Array<Int> // a generic type, Array, containing integers
any<P1, P2> // a protocol composition of two protocols

In this case, would we want to support "any<>" in addition to Any? The parsing issues should go away, since these are two different identifiers.

Isn鈥檛 `Any` a typealias for `any<>`? If so, we have to support `any<>`! :slight_smile:

路路路

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

Austin

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

On May 20, 2016, at 2:00 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think you should submit this for review, but I also think you should take the part of your older proposal to add class support to Any<...> and submit it as a separate proposal. (I mean, the part where you can define things like "Any<UIViewController, Protocol>" or "Any<class, Protocol>".)

Yes, it is additive, but even getting that feature into Swift 3 would be an enormous benefit if it can be implemented easily. And the core team is probably better positioned than anyone else to determine whether that's true.

Austin, what is your thought on switching to `any` rather than `Any` since it does not behave like a user-defined generic type? The convention is for types to be uppercase and keywords to be lowercase. This falls more into the category of a keyword and has its own behavior distinct from the behavior of all generic types. Making it stand out syntactically will help to make that clear.

Austin

On Fri, May 20, 2016 at 2:39 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This is a follow up proposal to SE-0095 <https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md> which should be considered for Swift 3 if SE-0095 will be accepted.

Here is the formatted draft: https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md

Please provide your feedback in this thread, and don鈥檛 make a race who is making a better proposal on the exact same topic.

If you spot any types or other mistakes I鈥檇 be happy to see you pointing me to them. :wink:

--
Adrian Zubarev
Sent with Airmail

Disallow redundant Any<...> constructs

Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author: Adrian Zubarev <https://github.com/DevAndArtist>
Status: Awaiting review <>
Review manager: TBD
Introduction

This is a follow up proposal to SE鈥0095 <https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md>, if it will be accepted for Swift 3. The current concept of Any<...> introduced in SE鈥0095 will allow creation of redundant types like Any<A> == A. I propose to disallow such redundancy in Swift 3 to prevent breaking changes in a future version of Swift.

Swift-evolution thread: [Proposal] Disallow redundant Any<...> constructs <>
Motivation

If SE鈥0095 will be accepted there will be future proposals to enhance its capabilities. Two of these will be Any-type requirement (where type could be class, struct or enum) and Class requirement. Without any restrictions these will introduce more redundancy.

As said before it is possible to create redundant types like Any<A> == A or endless shadowed redundant nesting:

typealias A_1 = Any<A>
typealias A_2 = Any<A_1>
typealias A_3 = Any<A_2>
/* and so on */
This proposal should ban redundancy right from the beginning. If there might be any desire to relax a few things, it won鈥檛 introduce any breaking changes for Any<...> existential.

Proposed solution

If empty Any<> won鈥檛 be disallowed in SE鈥0095, we should disallow nesting empty Any<> inside of Any<...>.

Disallow nesting Any (type refers to current typealias Any = protocol<>) inside of Any<...>.

Disallow Any<...> containing a single Type like Any<Type>.

The first three rules will ban constructs like Any<Any<>, Type> or Any<Any, Type> and force the developer to use Type instead.

Disallow nesting a single Any<...> inside another Any<...>.
e.g. Any<Any<FirstType, SecondType>>
Disallow same type usage like Any<A, A> or Any<A, B, A> and force the developer to use A or Any<A, B> if A and B are distinct.

Disallow forming redundant types when the provided constraints are not independent.

// Right now `type` can only be `protocol` but in the future Any<...>
// could also allow `class`, `struct` and `enum`.
// In this example `B` and `C` are distinct.
type A: B, C {}
聽聽聽聽聽
// all following types are equivalent to `A`
Any<A, Any<B, C>>
Any<Any<A, B>, C>
Any<Any<A, C>, B>
Any<A, B, C>
Any<A, B>
Any<A, C>
If all contraints form a known Type provide a Fix-it error depending on the current context. If there is more than one Type, provide all alternatives to the developer.

Using Any<...> in a generic context might not produce a Fix-it error:

protocol A {}
protocol B {}
protocol C: A, B {}
聽聽聽聽聽聽聽聽聽
// there is no need for `Fix-it` in such a context
func foo<T: Any<A, B>>(value: T) {}
Impact on existing code

These changes will break existing code. Projects abusing Any<...> to create redundant types should be reconsidered of usings the equivalent Type the compiler would infer. One would be forced to use A instead of Any<A> for example. A Fix-it error message can help the developer to migrate his project.

Alternatives considered

Leave redundancy as-is for Swift 3 and live with it.
Deprecate redundancy in a future version of Swift, which will introduce breaking changes.

_______________________________________________
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


(Brent Royal-Gordon) #12

Austin, what is your thought on switching to `any` rather than `Any` since it does not behave like a user-defined generic type? The convention is for types to be uppercase and keywords to be lowercase. This falls more into the category of a keyword and has its own behavior distinct from the behavior of all generic types. Making it stand out syntactically will help to make that clear.

You didn't ask me, but I'll weigh in: I'm not a fan.

* I think `Any` (without parameters) should be uppercase, and I don't think we should have both `Any` and `any<>` or `any`. Death to the typealias!
* If type-erasing structs like `AnySequence` are eventually subsumed by this syntax, I would prefer they be called `Any<Sequence>` instead of `any<Sequence>`.
* In the `willSet` vs. `willset` thread, I proposed a rule that keywords which fit into a particular syntactic slot should be capitalized like normal members of that slot. For instance, if `dynamicType` is a pseudo-property, it should be capitalized like a property. Since `Any<>` fits in the syntactic slot of a type, it should be capitalized like a type.

路路路

--
Brent Royal-Gordon
Architechies


(Adrian Zubarev) #13

I鈥檓 referring to this talk form the SE-0095 thread:

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

To that end, I鈥檇 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'.

We could allow everything. Personally I wouldn鈥檛 care much, because of best practice style. But if we will decide to restrict something after Swift 3 drops this will break code again, which we want to avoid, am I right?

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:40:03, Matthew Johnson (matthew@anandabits.com) schrieb:

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

I don't understand what you mean. I definitely think your 'typealias ABC = Any<AB, C>' should be valid.
I said typealias ABC = Any<AB, C> is valid.

Where

typealias AliasA = Any<A>

is not and furthermore

typealias AliasAA = Any<AliasA>

should also not be valid because Any<Any<A>> shouldn鈥檛 be valid.

IMO the rules around banning nested any are unnecessary complexity. The constructs have a well defined meaning. The argument to ban them is purely around limiting allowable syntactic style. People are very unlikely to actually use this nesting except through the abstraction of a typealias which is a very valid use case. The complexity of the rules does not appear to provide any tangible benefit.

Which rule(s) do you refer to exactly?

Any rules that ban syntactic constructs which have a well defined meaning on purely stylistic grounds. Those introduce unnecessary complexity for little, if any benefit. As Tony points out, it is possible that such bans would have unintended consequences and ban useful constructs. It is not worth the effort to try to ensure they don鈥檛 have unintended consequences.

We rely on people to do sensible things stylistically all the time (Swift does not enforce code layout like some languages do). I don鈥檛 see why `Any` should be different.

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:12:40, Matthew Johnson (matthew@anandabits.com) schrieb:

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


(L Mihalkovic) #14

Regards
(From mobile)

I don't understand what you mean. I definitely think your 'typealias ABC = Any<AB, C>' should be valid.

I said typealias ABC = Any<AB, C> is valid.

Where

typealias AliasA = Any<A>

is not and furthermore

typealias AliasAA = Any<AliasA>

should also not be valid because Any<Any<A>> shouldn鈥檛 be valid.

IMO the rules around banning nested any are unnecessary complexity. The constructs have a well defined meaning. The argument to ban them is purely around limiting allowable syntactic style. People are very unlikely to actually use this nesting except through the abstraction of a typealias which is a very valid use case. The complexity of the rules does not appear to provide any tangible benefit.

Which rule(s) do you refer to exactly?

Any rules that ban syntactic constructs which have a well defined meaning on purely stylistic grounds. Those introduce unnecessary complexity for little, if any benefit. As Tony points out, it is possible that such bans would have unintended consequences and ban useful constructs. It is not worth the effort to try to ensure they don鈥檛 have unintended consequences.

If i am not mistaken, linters exist so that these rules can be created an enforced without having to introduce special cases in compilers.

路路路

On May 20, 2016, at 5:39 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

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

We rely on people to do sensible things stylistically all the time (Swift does not enforce code layout like some languages do). I don鈥檛 see why `Any` should be different.

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:12:40, Matthew Johnson (matthew@anandabits.com) schrieb:

_______________________________________________
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


(Adrian Zubarev) #15

+1 for this as the original post suggested already `type<鈥>` or `all<鈥>`. `any<鈥>` is fine here.

Wrong thread though. :smiley:

路路路

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 21:07:20, Austin Zheng (austinzheng@gmail.com) schrieb:

I actually like "any<P1, P2>". It does provide that very distinctive visual signal that any<> is not a generic type, and that 'any' is not itself a type, but rather a special keyword for constructing an existential:

Array<Int> // a generic type, Array, containing integers
any<P1, P2> // a protocol composition of two protocols

In this case, would we want to support "any<>" in addition to Any? The parsing issues should go away, since these are two different identifiers.

Austin

On Fri, May 20, 2016 at 12:04 PM, Matthew Johnson <matthew@anandabits.com> wrote:

On May 20, 2016, at 2:00 PM, Austin Zheng via swift-evolution <swift-evolution@swift.org> wrote:

I think you should submit this for review, but I also think you should take the part of your older proposal to add class support to Any<...> and submit it as a separate proposal. (I mean, the part where you can define things like "Any<UIViewController, Protocol>" or "Any<class, Protocol>".)

Yes, it is additive, but even getting that feature into Swift 3 would be an enormous benefit if it can be implemented easily. And the core team is probably better positioned than anyone else to determine whether that's true.

Austin, what is your thought on switching to `any` rather than `Any` since it does not behave like a user-defined generic type? The convention is for types to be uppercase and keywords to be lowercase. This falls more into the category of a keyword and has its own behavior distinct from the behavior of all generic types. Making it stand out syntactically will help to make that clear.

Austin

On Fri, May 20, 2016 at 2:39 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

This is a follow up proposal to SE-0095 which should be considered for Swift 3 if SE-0095 will be accepted.

Here is the formatted draft: https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-ban-redundancy-in-any-existential.md

Please provide your feedback in this thread, and don鈥檛 make a race who is making a better proposal on the exact same topic.

If you spot any types or other mistakes I鈥檇 be happy to see you pointing me to them. :wink:

--
Adrian Zubarev
Sent with Airmail

Disallow redundant Any<...> constructs

Proposal: SE-NNNN
Author: Adrian Zubarev
Status: Awaiting review
Review manager: TBD
Introduction

This is a follow up proposal to SE鈥0095, if it will be accepted for Swift 3. The current concept of Any<...> introduced in SE鈥0095 will allow creation of redundant types like Any<A> == A. I propose to disallow such redundancy in Swift 3 to prevent breaking changes in a future version of Swift.

Swift-evolution thread: [Proposal] Disallow redundant Any<...> constructs

Motivation

If SE鈥0095 will be accepted there will be future proposals to enhance its capabilities. Two of these will be Any-type requirement (where type could be class, struct or enum) and Class requirement. Without any restrictions these will introduce more redundancy.

As said before it is possible to create redundant types like Any<A> == A or endless shadowed redundant nesting:

typealias A_1 = Any<A>
typealias A_2 = Any<A_1>
typealias A_3 = Any<A_2>
/* and so on */

This proposal should ban redundancy right from the beginning. If there might be any desire to relax a few things, it won鈥檛 introduce any breaking changes for Any<...> existential.

Proposed solution

If empty Any<> won鈥檛 be disallowed in SE鈥0095, we should disallow nesting empty Any<> inside of Any<...>.

Disallow nesting Any (type refers to current typealias Any = protocol<>) inside of Any<...>.

Disallow Any<...> containing a single Type like Any<Type>.

The first three rules will ban constructs like Any<Any<>, Type> or Any<Any, Type> and force the developer to use Type instead.

Disallow nesting a single Any<...> inside another Any<...>.
e.g. Any<Any<FirstType, SecondType>>
Disallow same type usage like Any<A, A> or Any<A, B, A> and force the developer to use A or Any<A, B> if A and B are distinct.

Disallow forming redundant types when the provided constraints are not independent.

// Right now `type` can only be `protocol` but in the future Any<...>
// could also allow `class`, `struct` and `enum`.
// In this example `B` and `C` are distinct.
type A: B, C {}
聽聽聽聽聽聽
// all following types are equivalent to `A`
Any<A, Any<B, C>>
Any<Any<A, B>, C>
Any<Any<A, C>, B>
Any<A, B, C>
Any<A, B>
Any<A, C>

If all contraints form a known Type provide a Fix-it error depending on the current context. If there is more than one Type, provide all alternatives to the developer.

Using Any<...> in a generic context might not produce a Fix-it error:

protocol A {}
protocol B {}
protocol C: A, B {}
聽聽聽聽聽聽聽聽聽聽
// there is no need for `Fix-it` in such a context
func foo<T: Any<A, B>>(value: T) {}

Impact on existing code

These changes will break existing code. Projects abusing Any<...> to create redundant types should be reconsidered of usings the equivalent Type the compiler would infer. One would be forced to use A instead of Any<A> for example. A Fix-it error message can help the developer to migrate his project.

Alternatives considered

Leave redundancy as-is for Swift 3 and live with it.
Deprecate redundancy in a future version of Swift, which will introduce breaking changes.

_______________________________________________
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


(Matthew Johnson) #16

I鈥檓 referring to this talk form the SE-0095 thread:

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

To that end, I鈥檇 suggest Any<>,Any<Any, XX>, and Any<Any<XX>> all cause warnings.

-DW

>
> 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
>
>
>>
>> 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)
>>
>>>
>>> - 'Any<>' should be allowed. You can currently use 'protocol<>' in your code instead of 'Any'.

We could allow everything. Personally I wouldn鈥檛 care much, because of best practice style. But if we will decide to restrict something after Swift 3 drops this will break code again, which we want to avoid, am I right?

If we wanted to do it it would probably be for a very good reason and we would probably be willing to accept the breakage. Let鈥檚 not introduce arbitrary and somewhat complex restrictions just because 鈥渨e can鈥檛 break code after Swift 3鈥.

路路路

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

> On May 19, 2016, at 12:43 AM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:
>> On May 18, 2016, at 11:33 PM, Colin Barrett <colin@springsandstruts.com <mailto:colin@springsandstruts.com>> wrote:
>>> On May 19, 2016, at 1:58 AM, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:40:03, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

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

I don't understand what you mean. I definitely think your 'typealias ABC = Any<AB, C>' should be valid.

I said typealias ABC = Any<AB, C> is valid.

Where

typealias AliasA = Any<A>

is not and furthermore

typealias AliasAA = Any<AliasA>

should also not be valid because Any<Any<A>> shouldn鈥檛 be valid.

IMO the rules around banning nested any are unnecessary complexity. The constructs have a well defined meaning. The argument to ban them is purely around limiting allowable syntactic style. People are very unlikely to actually use this nesting except through the abstraction of a typealias which is a very valid use case. The complexity of the rules does not appear to provide any tangible benefit.

Which rule(s) do you refer to exactly?

Any rules that ban syntactic constructs which have a well defined meaning on purely stylistic grounds. Those introduce unnecessary complexity for little, if any benefit. As Tony points out, it is possible that such bans would have unintended consequences and ban useful constructs. It is not worth the effort to try to ensure they don鈥檛 have unintended consequences.

We rely on people to do sensible things stylistically all the time (Swift does not enforce code layout like some languages do). I don鈥檛 see why `Any` should be different.

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:12:40, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

_______________________________________________
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


(Adrian Zubarev) #17

Ok fine your point is that we should not restrict redundancy in `Any<>`. Shall I still submit this to see what the core team thinks about it, even if it gets rejected?

路路路

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 18:08:44, Matthew Johnson (matthew@anandabits.com) schrieb:

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

I鈥檓 referring to this talk form the SE-0095 thread:

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

To that end, I鈥檇 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'.

We could allow everything. Personally I wouldn鈥檛 care much, because of best practice style. But if we will decide to restrict something after Swift 3 drops this will break code again, which we want to avoid, am I right?

If we wanted to do it it would probably be for a very good reason and we would probably be willing to accept the breakage. Let鈥檚 not introduce arbitrary and somewhat complex restrictions just because 鈥渨e can鈥檛 break code after Swift 3鈥.

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:40:03, Matthew Johnson (matthew@anandabits.com) schrieb:

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

I don't understand what you mean. I definitely think your 'typealias ABC = Any<AB, C>' should be valid.
I said typealias ABC = Any<AB, C> is valid.

Where

typealias AliasA = Any<A>

is not and furthermore

typealias AliasAA = Any<AliasA>

should also not be valid because Any<Any<A>> shouldn鈥檛 be valid.

IMO the rules around banning nested any are unnecessary complexity. The constructs have a well defined meaning. The argument to ban them is purely around limiting allowable syntactic style. People are very unlikely to actually use this nesting except through the abstraction of a typealias which is a very valid use case. The complexity of the rules does not appear to provide any tangible benefit.

Which rule(s) do you refer to exactly?

Any rules that ban syntactic constructs which have a well defined meaning on purely stylistic grounds. Those introduce unnecessary complexity for little, if any benefit. As Tony points out, it is possible that such bans would have unintended consequences and ban useful constructs. It is not worth the effort to try to ensure they don鈥檛 have unintended consequences.

We rely on people to do sensible things stylistically all the time (Swift does not enforce code layout like some languages do). I don鈥檛 see why `Any` should be different.

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:12:40, Matthew Johnson (matthew@anandabits.com) schrieb:

_______________________________________________
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


(Matthew Johnson) #18

Austin, what is your thought on switching to `any` rather than `Any` since it does not behave like a user-defined generic type? The convention is for types to be uppercase and keywords to be lowercase. This falls more into the category of a keyword and has its own behavior distinct from the behavior of all generic types. Making it stand out syntactically will help to make that clear.

You didn't ask me, but I'll weigh in: I'm not a fan.

Sorry, I asked Austin because he is heading up the proposal. Didn鈥檛 meant to leave anyone out. Thanks for providing feedback!

* I think `Any` (without parameters) should be uppercase, and I don't think we should have both `Any` and `any<>` or `any`. Death to the typealias!

Why do you think this? `any<>` (or `Any<>`) is replacing `protocol<>`. `protocol` is a keyword, so following the convention you shared it should be all lowercase. Aside from that, it behaves differently than a user-defined type (which would be uppercase).

* If type-erasing structs like `AnySequence` are eventually subsumed by this syntax, I would prefer they be called `Any<Sequence>` instead of `any<Sequence>`.

Are you arguing this because they are types? They are currently structs. If they were subsumed by this proposal they most definitely would not be structs. If it鈥檚 just syntax you鈥檙e concerned with, we could add a typealias:

typealias AnySequence<T> = any<Sequence where .Iterator.Element == T>

I haven鈥檛 evaluated AnySequence relative to the existential this typealias would produce. If the visible interface is compatible there would be a strong argument for introducing this typealias. The argument for lowercase wouldn鈥檛 apply to the typealias.

* In the `willSet` vs. `willset` thread, I proposed a rule that keywords which fit into a particular syntactic slot should be capitalized like normal members of that slot. For instance, if `dynamicType` is a pseudo-property, it should be capitalized like a property. Since `Any<>` fits in the syntactic slot of a type, it should be capitalized like a type.

Any has some overlap with types, but it cannot be used everywhere a type can. This is precisely why it should be lowercase. I don鈥檛 believe it falls under that exemption in your proposal. I believe it鈥檚 a good exemption when the keyword is indistinguishable to users from a normal member. I don鈥檛 believe it鈥檚 a good exemption when the behavior is 鈥渟pecial鈥 in some way.

-Matthew

路路路

On May 20, 2016, at 6:56 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

--
Brent Royal-Gordon
Architechies


(Adrian Zubarev) #19

Isn鈥檛 `Any` a typealias for `any<>`? If so, we have to support `any<>`! :slight_smile:
Yes it is and SE-0095 will cause that all types implicitly conform to empty any<>.

This still can be banned from any<any<>, A> because its useless and redundant. But is up to the core team to decide.

路路路

--
Adrian Zubarev
Sent with Airmail


(Matthew Johnson) #20

Ok fine your point is that we should not restrict redundancy in `Any<>`. Shall I still submit this to see what the core team thinks about it, even if it gets rejected?

Right now what we need to do is have a simple proposal to rename `protocol` to `any` to set the stage for the future enhancements (notice the lowercase of `any` which I believe is the right direction). It sounds like that is all that will be accomplished in the Swift 3 timeframe.

路路路

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

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 18:08:44, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

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

I鈥檓 referring to this talk form the SE-0095 thread:

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

To that end, I鈥檇 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'.

We could allow everything. Personally I wouldn鈥檛 care much, because of best practice style. But if we will decide to restrict something after Swift 3 drops this will break code again, which we want to avoid, am I right?

If we wanted to do it it would probably be for a very good reason and we would probably be willing to accept the breakage. Let鈥檚 not introduce arbitrary and somewhat complex restrictions just because 鈥渨e can鈥檛 break code after Swift 3鈥.

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:40:03, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

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

I don't understand what you mean. I definitely think your 'typealias ABC = Any<AB, C>' should be valid.

I said typealias ABC = Any<AB, C> is valid.

Where

typealias AliasA = Any<A>

is not and furthermore

typealias AliasAA = Any<AliasA>

should also not be valid because Any<Any<A>> shouldn鈥檛 be valid.

IMO the rules around banning nested any are unnecessary complexity. The constructs have a well defined meaning. The argument to ban them is purely around limiting allowable syntactic style. People are very unlikely to actually use this nesting except through the abstraction of a typealias which is a very valid use case. The complexity of the rules does not appear to provide any tangible benefit.

Which rule(s) do you refer to exactly?

Any rules that ban syntactic constructs which have a well defined meaning on purely stylistic grounds. Those introduce unnecessary complexity for little, if any benefit. As Tony points out, it is possible that such bans would have unintended consequences and ban useful constructs. It is not worth the effort to try to ensure they don鈥檛 have unintended consequences.

We rely on people to do sensible things stylistically all the time (Swift does not enforce code layout like some languages do). I don鈥檛 see why `Any` should be different.

--
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 17:12:40, Matthew Johnson (matthew@anandabits.com <mailto:matthew@anandabits.com>) schrieb:

_______________________________________________
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