I think it makes sense to require class bounds to be first, for the same reason they must be first in. Lass inheritance clauses: to encourage consistency and make it more clear when some type has an ambiguous name (which shouldn't happen, but...)
-Chris > On Jan 29, 2017, at 9:03 AM, Kevin Nattinger via swift-evolution > <[email protected]> wrote: > > +1 on including concrete types, this is currently a gaping hole in the > language. > -100 on requiring the concrete type to be first. If I want to specify the > types alphabetically, grouped by module, or any other way I choose, why > should I not be allowed to do so? The compiler can warn on redundancies and > error on contradictions, that’s all we really need. > >> On Jan 29, 2017, at 8:39 AM, David Hart via swift-evolution >> <[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 >> >> Regards, >> David. >> >> Existentials for classes conforming to protocols >> Proposal: SE-XXXX >> Authors: David Hart, Austin Zheng >> Review Manager: TBD >> Status: TBD >> 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. >> >> 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. >> >> 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 >> 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. >> Alternatives considered >> >> None. >> >> Acknowledgements >> >> Thanks to Austin Zheng and Matthew Johnson 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 > > _______________________________________________ > 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
