I'm honestly not sure it makes sense to introduce a proposal just for expressing <Class, Protocol, Protocol> style requirements, and then trying to retrofit fuller support for other existentials onto it. I would prefer that the 'basic package' of existential cases be considered together as a single proposal, unless a core team member expresses their preference otherwise.
Austin On Tue, May 17, 2016 at 1:02 PM, Matthew Johnson <[email protected]> wrote: > > On May 17, 2016, at 2:45 PM, Austin Zheng via swift-evolution < > [email protected]> wrote: > > Feel free to add as much of this proposal into yours as you want. > > > The trend is towards smaller proposals and introducing change in stages. > Since Adrian’s proposal is almost ready it’s probably best to move ahead > with it as-is and follow up with generalized existentials (yours), and then > possibly a third on “opening” existentials. > > > 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 > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
