<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="">My stuff is maintained by a single team. My problem is that Swift 2 is too immature to be usable on Linux, while Swift 3 is considered not production-grade on iOS/OSX. I have code that compiles for both platforms, and so it needs to support 2+3, 2 for Darwin and 3 for Linux.<div class=""><br class=""></div><div class="">I would really like to see a saner way to go about this than duplicating whole function definitions. Maybe that solution is to backport the new syntax, or to forward-port the old syntax with a warning.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 16, 2016, at 3:52 PM, Jonathan Tang <<a href="mailto:jonathan.d.tang@gmail.com" class="">jonathan.d.tang@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">FWIW the Python 3 migration found removal of old syntax and introduction of new syntax in the same release to be hugely problematic, and ended up back-porting a lot of Python 2 syntax features into 3.1 & 3.2 to ease the transition. The problem is that large codebases are very rarely controlled by a single team, and each sub-library usually has their own schedule for update, such that cutting over all at once is not possible. The approach usually needs to be<div class=""><br class=""></div><div class="">1. Introduce the new syntax</div><div class="">2. Deprecate the old syntax, with fixits and strong warnings about when it'll be removed.</div><div class="">3. Allow at least one version (and usually a couple) to pass as a transition.</div><div class="">4. Remove the old syntax.</div><div class=""><br class=""></div><div class="">Not sure how much of a problem this'll be for Swift, which has had some pretty clear "things may break with Swift 3" warnings on it. My own organization is small, and can probably cut over all at once as long as there's a migration tool. But I've worked in big organizations where upgrading would be a complete non-starter if there's no transitional syntax that's compatible with both old and new compilers, and once Swift gets a decent third-party library ecosystem it'd be impractical to ever upgrade until library dependencies were upgraded, and it'd be impractical to upgrade the libraries until all their clients had switched. Deadlock. </div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Apr 16, 2016 at 3:55 AM, Drew Crawford via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hello,<div class=""><br class=""></div><div class="">I'm writing to complain about SE-0031 and Swift 2 compatibility. I understand (and agree with!) the change, but the migration between now and 2017 is annoying, hence my complaint.</div><div class=""><br class=""></div><div class="">In snapshot swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a, we started erroring on the old syntax. That means that this:</div><div class=""><br class=""></div><div class=""> func foo(inout bar: Int) { }</div><div class=""><br class=""></div><div class="">is not legal Swift 3.</div><div class=""><br class=""></div><div class="">...however, the new syntax:</div><div class=""><br class=""></div><div class=""> func foo(bar: inout Int) { }</div><div class=""><br class=""></div><div class="">is not legal Swift 2. This complicates compiling for both, which several of my projects currently do.</div><div class=""><br class=""></div><div class="">/<i class="">Further complicating matters</i>/, Swift does not understand line-scoped ifdefs. So this:</div><div class=""><br class=""></div><div class=""><div class=""> #if swift(>=3.0)</div><div class=""> func foo(bar: inout Int) {</div><div class=""> #else</div><div class=""> func foo(inout bar: Int) {</div><div class=""> #endif</div><div class=""> //my</div><div class=""> //long</div><div class=""> //functon</div><div class=""> //definition</div><div class=""> }</div></div><div class=""><br class=""></div><div class="">Is not legal Swift. The only way I know of is to say:</div><div class=""><br class=""></div><div class=""> #if swift(>=3.0)<br class=""> func foo(bar: inout Int) {<br class=""> //my<br class=""> //long<br class=""> //functon<br class=""> //definition<br class=""> }<br class=""> #else<br class=""> func foo(inout bar: Int) {<br class=""> //my<br class=""> //long<br class=""> //functon<br class=""> //definition<br class=""> }<br class=""> #endif</div><div class=""><br class=""></div><div class="">which forces duplication of the entire function definition.</div><div class=""><br class=""></div><div class="">My suggestion would be one or more of the following:</div><div class=""><br class=""></div><div class="">1. Support both syntaxes in Swift 3 "trunk" (e.g. until Swift 3 is released).</div><div class="">2. Backport the new syntax to Swift 2.2</div><div class="">3. Consider allowing line-scoped ifdefs</div><div class=""><br class=""></div><div class="">Thanks for reading, and sorry to rain on a parade I largely think is Good For Swift ™</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Drew</div></font></span></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>