SE-0031 and Swift 2


(Drew Crawford) #1

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


(Jonathan Tang) #2

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


(Drew Crawford) #3

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@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