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

Fri May 20 14:20:17 CDT 2016

> On May 20, 2016, at 2:07 PM, Austin Zheng <austinzheng at gmail.com> wrote:
> 
> 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’t `Any` a typealias for `any<>`?  If so, we have to support `any<>`! :)

> 
> Austin
> 
> 
> 
> On Fri, May 20, 2016 at 12:04 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
> 
>> On May 20, 2016, at 2:00 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at 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 <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 <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’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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/98635c3a/attachment.html>