Not true, we already stated a clear rule how existentials should work with class-requirements long time ago (don’t mind lowercased any here):
Nested any<...> A nested any<...> may declare a class or any-class constraint, even if its parent any<...> contains a class or any-class constraint, or a sibling any<...> constraint declares a class or any-class constraint. However, one of the classes must be a subclass of every other class declared within such constraints, or all the classes must be the same. This class, if it exists, is chosen as the any<...> construct’s constraint. // Can be any type that is a UITableView conforming to ProtocolA. // UITableView is the most specific class, and it is a subclass of the other // two classes. let a : any<UIScrollView, any<UITableView, any<UIView, ProtocolA>>> // REDUNDANT: could be banned by another proposal. // Identical to any<ProtocolA, ProtocolB> let b : any<any<ProtocolA, ProtocolB>> // NOT ALLOWED: no class is a subclass of all the other classes. This cannot be // satisfied by any type. let c : any<NSObject, any<UIView, any<NSData, ProtocolA>>> Using typealiases, it is possible for any<...> existentials to be composed. This allows API requirements to be expressed in a more natural, modular way: // Any custom UIViewController that serves as a delegate for a table view. typealias CustomTableViewController = any<UIViewController, UITableViewDataSource, UITableViewDelegate> // Pull in the previous typealias and add more refined constraints. typealias PiedPiperResultsViewController = any<CustomTableViewController, PiedPiperListViewController, PiedPiperDecompressorDelegate> Any any<...> containing nested any<...>s can be conceptually ‘flattened’ and written as an equivalent any<...> containing no nested any<...> requirements. The two representations are exactly interchangeable. That said, your example won’t work just because UIViewController and UIWindow are not compatible. The whole class-requirement is not based on the base types of all provided classes, but checked their own relationship instead. -- Adrian Zubarev Sent with Airmail Am 14. Juni 2016 um 21:25:31, L. Mihalkovic ([email protected]) schrieb: Which addresses the fact that nons of the proposals so far truly prevent absurde declarations like: Let v: Any< UIViewController, UIWindow, UITableViewDelegate> Let v: UIViewController & UIWindow & UITableViewDelegate
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
