[swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

Fri May 20 14:09:40 CDT 2016

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

Wrong thread though. :D

-- 
Adrian Zubarev
Sent with Airmail

Am 20. Mai 2016 bei 21:07:20, Austin Zheng (austinzheng at 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 at anandabits.com> wrote:

On May 20, 2016, at 2:00 PM, Austin Zheng via swift-evolution <swift-evolution at 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 at 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’t make a race who is making a better proposal on the exact same topic.

If you spot any types or other mistakes I’d be happy to see you pointing me to them. ;)

-- 
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’t introduce any breaking changes for Any<...> existential.

Proposed solution

If empty Any<> won’t 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 at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/ece21c05/attachment.html>