Placement of `inout`

[vapor]

Placement of `inout`

[shnhrrsn]

We should absolutely update to fix this.

That said, I would like to formalize a guideline/timeline around when we update for breaking changes. Despite the warnings, everything compiles on the 03-01 snapshot where as any snapshot before 03-01 will result in a error error.

@qutheory/vapor:

1. What timeframe is sufficient to expect/force everyone to have upgraded all of their environments? Currently we're at 10 days, is that enough?
2. Would a snapshot+1 policy make sense, where if you don't upgrade by the snapshot following the breaking change, it's on you?
3. Given the early stages of Vapor, should we just make these changes immediately upon release?

[ketzusaka]

If we make that change were also incompatible with iOS and Swift 2.2 until the fall. We should probably do Swift version compiler checks.

[tanner0101]

Our goal is compatibility with Swift 2.2. So, if we want to get rid of those warnings then we should unfortunately do version checking.

[tanner0101]

@shnhrrsn Given the scope and early stage of Vapor, I think we are fine to be compatible with only the latest snapshots, and to require that everyone is running the latest ones.

I'd make our support requirements the following:

• Latest Swift 2.2 Release Snapshot
• Latest Development Snapshot

We should upgrade Travis CI to test these both.

[czechboy0]

I might be missing something, but what's the point of supporting 2.2 when only 3.0 contains SwiftPM, which is the only supported way to build Vapor? Even if you make it compatible with 2.2, nobody will use it with it.

[ketzusaka]

@czechboy0 I was actually hoping we'd make it cocoapod/carthage compatible after Xcode 7.3 is released.

[tanner0101]

If Vapor doesn't work with Swift 2.2 when it's released that would be ridiculous. We will find a way.

[czechboy0]

I'm not saying there isn't a way, all I'm saying is that Swift 3 as a platform, not as a language, is the first milestone where Vapor even makes sense.

Maybe my misunderstanding comes from the expectations of where Vapor will run. My guess is that absolute majority will be on Linux servers, where SwiftPM is the only way to build/run Vapor. There really aren't that many Mac servers, where you'd have the luxury of having Xcode installed, so I don't see how CocoaPods/Carthage even makes sense for a serverside project.

Feel free to introduce a bunch of compile-time checks for 2.2, but for a project which won't be able to run on 2.2 (unless you introduce a bunch of converters from Package.swift to the aforementioned package managers for the sake of being able to run on a few Mac servers), and which is still in active development, already introducing legacy feels like a very bad idea to me, mostly because I don't understand who you're trying to enable to use Vapor who already can't use Swift 3.0-dev.

The way I understood it was that Vapor is a Swift 3.0/SwiftPM targetting project, meaning you can already run it on servers with Swift 3.0-dev (whichever platform). But I didn't know backwards compatibility to language versions which don't support SwiftPM was a goal.

[tanner0101]

Vapor shouldn't require SwiftPM if NSJSON gets fixed.

[tanner0101]

Even if we have to bundle things manually to work with Swift 2.2, even if we have to make a branch, we should do that. I think it would be a major disadvantage for Vapor to not work with the release version of Swift on Linux.

[czechboy0]

IMO Swift 2.2 on Linux won't be very useful without SwiftPM. But it's your call, "ifdef" away :)

[tanner0101]

Yeah, I think that was really stupid on Apple's part. But nothing we can do about that. :\

[ketzusaka]

@czechboy0 It certainly won't be good to develop on, but I feel like we could build a package for apt-get or similar that runs in the swift2.2 runtime and wouldn't need SPM.

[tanner0101]

Exactly. I don't know what the schedule is like for Swift 2.2 release and Swift 3.0 release...I assume they would be at least 6 months apart. That's a lot of time to delay a 1.0.0 release.

[czechboy0]

I guess my question is: who are the people who will not be able to use 3.0-dev that we're optimizing here for? It's so easy to switch swift versions that I seriously doubt the effort to run on 2.2 forever is justified.

[tanner0101]

Vapor can't be production ready until it runs on a released compiler.