<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Howdy,<div class=""><br class=""></div><div class="">There is already an accepted but not implemented proposal to determine whether a module can be imported and conditionally compile accordingly.<div class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md</a></div><div class=""><br class=""></div><div class="">While the accepted change is certainly not as compact as your notation, it has the advantage that it supports more functionality. I could, for example, include code in a file for UIKit, Cocoa, WatchKit and ostensibly some Linux UI framework depending on my target platform. If my functionality is intended around adding a single consistent feature to a Type in each module, then this is how I want to organize my code.</div><div class=""><br class=""></div><div class="">Besides, “||” is so JavaScript. In Swift it would be “??”, and it would potentially need to chain because there are more than 2 supported platforms.</div><div class=""><br class=""></div><div class="">Finally, I don’t see how you handle failure to import a module. Does compile fail, or do you provide your own implementation of the desired functionality? When Apple adds a module on one platform but not on another, then I might need to write my own implementation for platforms on which it is missing, but depend on system integrated performance on the platforms they provide it for. “canimport” provides for either using other existing # patterns, but your proposal does not.</div><div class=""><br class=""></div><div class="">So I recommend checking out the already-accepted proposal. But if you still need the syntax to get smaller, at least move to “??” so it looks like Swift instead of some other language.</div><div class=""><br class=""></div><div class="">-Ben<br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 17, 2016, at 5:05 PM, Sean Alling via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><u class=""><b class="">Description</b></u></div><div class=""><br class=""></div><div class="">In an effort to both (1) reduce boilerplate code, and (2) promote cross-platform reusability I propose that we implement the following <b class="">Import Conditional Operators</b>: </div><div class=""><br class=""></div><div class=""><b class="">`||` </b>and `<b class="">&&`</b></div><div class=""><b class=""><br class=""></b></div><div class="">Currently, import conditionals must be implemented like so:</div><div class=""><br class=""></div><div class="">```</div><div class="">#if os(Linux) || os(FreeBSD)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>import Glibc<br class="">#else<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>import Darwin<br class="">#endif</div><div class="">```</div><div class=""><br class=""></div><div class="">With <b class="">import conditional operators</b> this would be condensed to:</div><div class=""><br class=""></div><div class="">```</div><div class="">import Glibc || Darwin</div><div class="">```</div><div class=""><br class=""></div><div class="">The first library/framework (Glibc) would be imported if found and the the second (Darwin) only in the event the first should fail.</div><div class=""><br class=""></div><div class=""><b class=""><u class="">Other Caveats:</u></b></div><div class=""><b class=""><u class=""><br class=""></u></b></div><div class=""><b class="">(A) — </b>we could limit this to one conditional operator per import line OR we could implement order of operations. Obviously, there are tradeoffs of both that we should discuss.</div><div class=""><br class=""></div><div class=""><b class="">(B) —</b> if-conditional statements currently explicitly show the import conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to this new feature. I would argue that the reduction of boilerplate code would in itself be worth this abstraction.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">--</div><div class="">Sean Alling</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>