Re: [swift-evolution] SE-0031 and Swift 2
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 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
> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] SE-0031 and Swift 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
[swift-evolution] SE-0031 and Swift 2
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
