[swift-evolution] SE-0031 and Swift 2

Drew Crawford drew at sealedabstract.com
Sat Apr 16 16:33:36 CDT 2016


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.tang at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160416/08b87aa4/attachment.html>


More information about the swift-evolution mailing list