> On May 17, 2016, at 3:06 PM, Austin Zheng <[email protected]> wrote: > > 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.
It also renames protocol<> to Any, but fair enough. One reason to keep it separate is that the rename is a breaking change and we should really try to get that into Swift 3. Generalizing existentials is an additive change. I would love to have that in Swift 3 as well, but if it’s not going to make it I don’t think it should hold back the smaller change which is a breaking change. Doug, any opinion on this? > > Austin > > On Tue, May 17, 2016 at 1:02 PM, Matthew Johnson <[email protected] > <mailto:[email protected]>> wrote: > >> On May 17, 2016, at 2:45 PM, Austin Zheng via swift-evolution >> <[email protected] <mailto:[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] <mailto:[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] <mailto:[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] <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] <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
