> On Feb 1, 2017, at 4:06 PM, Douglas Gregor <[email protected]> wrote: > > Personally, I like having the requirement that the class come first. It fits > with the requirement we already have for classes that have a superclass.
I guess I’ll throw my hat into the ring and +1 this too. What if there are multiple class bounds, though? We could simply ignore this requirement for typealiases, I suppose. > > - Doug > >> David. >> >>> On 1 Feb 2017, at 22:58, Douglas Gregor <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>>> On Jan 29, 2017, at 8:39 AM, David Hart <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Hello, >>>> >>>> As promised, I wrote the first draft of a proposal to add class >>>> requirements to the existential syntax. Please let me know what you think. >>>> >>>> https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/XXXX-subclass-existentials.md >>>> >>>> <https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/XXXX-subclass-existentials.md> >>> This looks good! I’m looking forward to the second draft, but I have one >>> question. >>> >>> Did you consider the generalized “class” constraint? IIRC, this was in >>> Austin’s larger proposal, and it allowed for (e.g.) >>> >>> typealias CustomStringConvertibleClass = class & >>> CustomStringConvertible // class that conforms to CustomStringConvertible >>> >>> and potentially a wonderful cleanup where AnyObject ceases to be a weird >>> special protocol and instead becomes >>> >>> typealias AnyObject = Any & class >>> >>> >>> - Doug >>> >>>> Regards, >>>> David. >>>> >>>> Existentials for classes conforming to protocols >>>> >>>> Proposal: SE-XXXX >>>> <https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/XXXX-subclass-existentials.md> >>>> Authors: David Hart <http://github.com/hartbit/>, Austin Zheng >>>> <http://github.com/austinzheng> >>>> Review Manager: TBD >>>> Status: TBD >>>> >>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#introduction>Introduction >>>> >>>> This proposal brings more expressive power to the type system by allowing >>>> Swift to represent existentials of classes and subclasses which conform to >>>> protocols. >>>> >>>> >>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#motivation>Motivation >>>> >>>> Currently, the only existentials which can be represented in Swift are >>>> conformances to a set of protocols, using the &syntax: >>>> >>>> let existential: Hashable & CustomStringConvertible >>>> On the other hand, Objective-C is capable of expressing existentials of >>>> subclasses conforming to protocols with the following syntax: >>>> >>>> UIViewController<UITableViewDataSource, UITableViewDelegate>* existential; >>>> We propose to provide similar expressive power to Swift, which will also >>>> improve the bridging of those types from Objective-C. >>>> >>>> >>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#proposed-solution>Proposed >>>> solution >>>> >>>> The proposal keeps the existing & syntax but allows the first element, and >>>> only the first, to be of class type. The equivalent declaration to the >>>> above Objective-C declaration would look like this: >>>> >>>> let existential: UIViewController & UITableViewDataSource & >>>> UITableViewDelegate >>>> As in Objective-C, this existential represents classes which have >>>> UIViewController in their parent inheritance hierarchy and which also >>>> conform to the UITableViewDataSource and UITableViewDelegate protocols. >>>> >>>> As only the first element in the existential composition syntax can be a >>>> class type, and by extending this rule to typealias expansions, we can >>>> make sure that we only need to read the first element to know if it >>>> contains a class requirement. As a consequence, here is a list of valid >>>> and invalid code and the reasons for them: >>>> >>>> let a: Hashable & CustomStringConvertible >>>> // VALID: This is still valid, as before >>>> >>>> let b: MyObject & Hashable >>>> // VALID: This is the new rule which allows an object type in first >>>> position >>>> >>>> let c: CustomStringConvertible & MyObject >>>> // INVALID: MyObject is not allowed in second position. A fix-it should >>>> help transform it to: >>>> // let c: MyObject & CustomStringConvertible >>>> >>>> typealias MyObjectStringConvertible = MyObject & CustomStringConvertible >>>> let d: Hashable & MyObjectStringConvertible >>>> // INVALID: The typealias expansion means that the type of d expands to >>>> Hashable & MyObject & CustomStringConvertible, which has the class in the >>>> wrong position. A fix-it should help transform it to: >>>> // let d: MyObjectStringConvertible & Hashable >>>> >>>> typealias MyObjectStringConvertible = MyObject & CustomStringConvertible >>>> let e: MyOtherObject & MyObjectStringConvertible >>>> // INVALID: The typealias expansion would allow an existential with two >>>> class requirements, which is invalid >>>> The following examples could technically be legal, but we believe we >>>> should keep them invalid to keep the rules simple: >>>> >>>> let a: MyObject & MyObject & CustomStringConvertible >>>> // This is equivalent to MyObject & CustomStringConvertible >>>> >>>> let b: MyObjectSubclass & MyObject & Hashable >>>> // This is equivalent to MyObjectSubclass & Hashable >>>> >>>> typealias MyObjectStringConvertible = MyObject & CustomStringConvertible >>>> let d: MyObject & MyObjectStringConvertible >>>> // This is equivalent to MyObject & CustomStringConvertible >>>> >>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#source-compatibility>Source >>>> compatibility >>>> >>>> This is a source breaking change. All types bridged from Objective-C which >>>> use the equivalent Objective-C feature import without the protocol >>>> conformances in Swift 3. This change would increase the existential's >>>> requirement and break on code which does not meet the new protocol >>>> requirements. For example, the following Objective-C code: >>>> >>>> @interface MyViewController >>>> - (void)setup:(nonnull >>>> UIViewController<UITableViewDataSource,UITableViewDelegate>*)tableViewController; >>>> @end >>>> is imported into Swift 3 as: >>>> >>>> class MyViewController { >>>> func setup(tableViewController: UIViewController) {} >>>> } >>>> which allows calling the function with an invalid parameter: >>>> >>>> let myViewController: MyViewController() >>>> myViewController.setup(UIViewController()) >>>> The previous code would have worked as long as the Objective-C code did >>>> not call any method of UITableViewDataSource or UITableViewDelegate. But >>>> if this proposal is accepted and implemented as-is, the Objective-C code >>>> would now be imported as: >>>> >>>> class MyViewController { >>>> func setup(tableViewController: UIViewController & >>>> UITableViewDataSource & UITableViewDelegate) {} >>>> } >>>> That would then cause the Swift code to fail to compile with an error >>>> which states that UIViewController does not conform to the >>>> UITableViewDataSource and UITableViewDelegate protocols. >>>> >>>> It is a source-breaking change, but should have a minimal impact for the >>>> following reasons: >>>> >>>> Not many Objective-C code used the existential syntax in practice. >>>> There generated errors are a good thing because they point out potential >>>> crashes which would have gone un-noticed. >>>> >>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#alternatives-considered>Alternatives >>>> considered >>>> >>>> None. >>>> >>>> >>>> <https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#acknowledgements>Acknowledgements >>>> >>>> Thanks to Austin Zheng <http://github.com/austinzheng> and Matthew Johnson >>>> <https://github.com/anandabits> who brought a lot of attention to >>>> existentials in this mailing-list and from whom most of the ideas in the >>>> proposal come from. >>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
