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