I new this was going to happen... of course with enough code around you can prevent anything. But that was precisely my point: with that proposal, these rules are the only way to make sure that something as clearly wrong as my simple example cannot happen. And this is to me the worst possible way to enforce it. I don't expect you will understand why, much less agree that it is. But if you do close your eyes and picture what the code will look like to do what you pasted here versus what I suggest, I hope you can see the clear difference between the 2 solutions...
To me, this is the archetype for a bad unnecessarily complicated, difficult to implement, solution which will be a lot of work to explain to people. This solution on the other hand is mechanically simple (because of its structure), and simple to explain https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051 Btw, it is not the only way to do something simple, which the following is absolutely not: > On Jun 14, 2016, at 11:41 PM, Adrian Zubarev via swift-evolution > <swift-evolution@swift.org> wrote: > > 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.mihalko...@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 > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
