Feel free to add as much of this proposal into yours as you want. Austin
On Tue, May 17, 2016 at 12:09 PM, Adrian Zubarev via swift-evolution < [email protected]> wrote: > +1 for extending my proposal and making `Any<>` even more a powerful > beast. :) > > -- > Adrian Zubarev > Sent with Airmail > > Am 17. Mai 2016 bei 20:52:34, Austin Zheng via swift-evolution ( > [email protected]) schrieb: > > I put together the skeleton of a proposal detailing enhancements to how > associated types can be referenced in Swift 3+. It's certainly not ready > for submission, but I think it gets across my ideas pretty well. Would love > to gather feedback and especially improvements. > > Be unsparing; whatever form this feature takes will profoundly affect how > Swift developers program for years, so it needs to be done right. > > See below: > > *Proposal* > > An existential type is defined using the "Any<...>" construct. Existential > types can be nested. > > The empty existential type "Any<>" is typealiased to 'Any'. > > Within the angle brackets are zero or more 'clauses'. Clauses are > separated by semicolons. (This is so commas can be used in where > constraints, below. Better ideas are welcome. Maybe it's not necessary; we > can use commas exclusively.) > > There are five different possible clauses: > > > - 'class'. Must be the first clause, if present. Places a constraint > on the existential to be any class type. (Implies: Only one can exist. > Mutually exclusive with class name clause.) > > > (In the future a follow-up proposal should add in 'struct' or 'value' as a > counterpart.) > > > - Class name. Must be the first clause, if present. (Implies: Only one > can exist. Mutually exclusive with 'class'.) Places a constraint on the > existential (not really an existential anymore) to be an instance of the > class, or one of its subclasses. > > Example: Any<UIViewController; UITableViewDataSource; UITableViewDelegate> > "Any UIViewController or subclass which also satisfies the table view data > source and delegate protocols" > > - Dynamic protocol. This is entirely composed of the name of a > protocol which has no associated types or Self requirement. > > > Example: Any<CustomStringConvertible; BooleanType> > "Any type which conforms to both the CustomStringConvertible and > BooleanType protocols" > > I'm going to use 'static protocol' to refer to a protocol with associated > types or self requirements. Feel free to propose a more sound name. > > > - Self-contained static protocol, simple. This is composed of the name > of a static protocol, optionally followed by a 'where' clause in which the > associated types can be constrained (with any of the three basic > conformance types: subclassing, protocol conformance, or type equality). > Associated types are referred to with a leading dot. > > > Example: Any<Collection where .Generator.Element : NSObject, > .Generator.Element : SomeProtocol> > "Any type that is a Collection, whose elements are NSObjects or their > subclasses conforming to SomeProtocol." > > > - Bound static protocol. This is the same as a self-contained static > protocol, but with a leading "<name> as " which binds the protocol to a > generic typealias. The name can be then be used in subsequent clauses to > build constraints. > > > Example: Any<T as Collection; IntegerLiteralConvertible where > .IntegerLiteralType == T.Element>. > "Any type that is a Collection, and also can be built from an integer > literal, in which the collection elements are the same type as the type of > the integer used for the integer literal conformance." > > There will be rules to prevent recursive nesting. For example, if generic > typealiases are allowed, they cannot refer to each other in a circular > manner (like how structs can't contain themeselves, and you can't create a > cyclic graph of enums containing themselves). > > How an existential can be used depends on what guarantees are provided by > the clauses. For example, 'Any<Equatable>' can't be used for much; if there > were any methods on Equatable that did not use the associated types at all > you'd be able to call them, but that's about it. However, 'Any<Equatable > where .Self == String>' would allow for == to be called on instances. (This > is a stupid example, since Any<Equatable where .Self == String> is > equivalent to 'String', but there are almost certainly useful examples one > could come up with.) > > In order of increasing 'power': > > - Don't constrain any associated types. You can pass around > Any<Equatable>s, but that's about it. > - Constrain associated types to conform to protocols. > - Fully constrain associated types. > > > > _______________________________________________ > 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
