[swift-evolution] Property with class and protocol type

[Adrian Zubarev]

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 (laurent.mihalkovic at gmail.com) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160614/542e1310/attachment.html>