> On May 20, 2016, at 2:07 PM, Austin Zheng <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > >> On May 20, 2016, at 2:00 PM, Austin Zheng via swift-evolution >> <[email protected] <mailto:[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 <> >> 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] <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
