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.
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. > On Apr 16, 2016, at 3:52 PM, Jonathan Tang <jonathan.d.t...@gmail.com> wrote: > > 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 > > 1. Introduce the new syntax > 2. Deprecate the old syntax, with fixits and strong warnings about when it'll > be removed. > 3. Allow at least one version (and usually a couple) to pass as a transition. > 4. Remove the old syntax. > > 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. > > On Sat, Apr 16, 2016 at 3:55 AM, Drew Crawford via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Hello, > > 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. > > In snapshot swift-DEVELOPMENT-SNAPSHOT-2016-04-12-a, we started erroring on > the old syntax. That means that this: > > func foo(inout bar: Int) { } > > is not legal Swift 3. > > ...however, the new syntax: > > func foo(bar: inout Int) { } > > is not legal Swift 2. This complicates compiling for both, which several of > my projects currently do. > > /Further complicating matters/, Swift does not understand line-scoped ifdefs. > So this: > > #if swift(>=3.0) > func foo(bar: inout Int) { > #else > func foo(inout bar: Int) { > #endif > //my > //long > //functon > //definition > } > > Is not legal Swift. The only way I know of is to say: > > #if swift(>=3.0) > func foo(bar: inout Int) { > //my > //long > //functon > //definition > } > #else > func foo(inout bar: Int) { > //my > //long > //functon > //definition > } > #endif > > which forces duplication of the entire function definition. > > My suggestion would be one or more of the following: > > 1. Support both syntaxes in Swift 3 "trunk" (e.g. until Swift 3 is released). > 2. Backport the new syntax to Swift 2.2 > 3. Consider allowing line-scoped ifdefs > > Thanks for reading, and sorry to rain on a parade I largely think is Good For > Swift ™ > > Drew > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
