<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I'm one of the largest dispatch-on-linux users right now. In fact, I'm reasonably sure I'm <b class="">THE</b> largest. I have an application in production that uses some 400 dispatch calls. <div class=""><br class=""></div><div class="">On Linux, I'm running Swift 3 in production, essentially because Dispatch/Linux in 2.2 does not even exist. On OSX/iOS, I compile the same codebase with Swift 2.2, because that's the version that's released, and using released software is a sane thing to do.</div><div class=""><br class=""></div><div class="">This proposal places me in the uncomfortable situation of trying to somehow smooth out a truly MASSIVE API delta with #if. And that's not going to happen. Realistically, what I will do is create some kind of FrankenSwift that either backports the new API to Swift 3 or the old API to Swift 2. And that is a ton of work, really stupid work, and I would infinitely prefer to spend that time doing something actually useful to the world. To be clear, I don't fear migration; what I fear is the heisenmigration, where one of my platforms must migrate, and the other ones can't.</div><div class=""><br class=""></div><div class="">More broadly, I am concerned about the direction the language is going where we do not even have working libraries yet and already we are doing sweeping API changes to them. I suspect this is motivated by a fundamentally incorrect premise–the premise that because it's not released yet, we can get away with it. When actually that's backwards: we can get away with breaking changes later, but if we do them now we will ruin everything. Let me explain.</div><div class=""><br class=""></div><div class="">Right now, Linux Swift programmers exist. And they need to be able to solve ordinary problems, like writing a string to a file, or spinning up a background thread. And I do mean: sometime before Late 2016. No amount of telling them "don't do that, it's not released" is going to stop this. The only question is whether upstream is going to be the repo that solves their problem, or whether they go to solve the problem somewhere else. Because when they go somewhere else, they invest there.</div><div class=""><br class=""></div><div class="">Increasingly, because upstream is not interested in the problem, I am seeing Linux folk go solve the problem somewhere else. Just counting the projects I'm personally aware of, there are 3 foundation alternatives and 1 package manager alternative. All because upstream has no sane path to e.g. reading a file on disk in the kind of timeframe working programmers actually need to do it in.</div><div class=""><br class=""></div><div class="">What we *should* be doing is creating libraries that *<b class="">work</b>*, *<b class="">releasing them</b>*, and then we can do as much API Disneyland as we want without harassing the working programmer.</div><div class=""><br class=""></div><div class="">1. If we're out of bugs to fix, why not release? Then folks like me can get off the snapshot treadmill and we won't be annoyed by massive API delta until we can do it all at once, which is (relatively) easy.</div><div class="">2. If we're not out of bugs to fix, why not work on them, and then release, and then come back to this?</div><div class="">3. Since Swift 3 will have a stable ABI, why not ship both libdispatch2 and libdispatch3 and let the programmer plan her own migration? I'm not even sure the stable ABI part is relevant, since Dispatch is almost entirely C.</div><div class=""><br class=""></div><div class="">All of these are saner alternatives to the proposal, and all of them achieve the stated goal (e.g. we still end up with happy modern APIs).</div><div class=""><br class=""></div><div class="">I don't mean to pick on this proposal specifically, I agree with the need to modernize the API surface area. But if we continue to do breaking changes first and releases later I'm concerned about where the early adopters will get pushed to.</div><div class=""><br class=""></div><div class="">Drew</div></body></html>