> On May 20, 2016, at 2:00 PM, Austin Zheng via swift-evolution > <[email protected]> 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 > <[email protected] <mailto:[email protected]>> 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 <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’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 > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > 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
