You do make some good points; we have a variety of important areas that are completely unimplemented across any platforms, besides the feature parity across platforms.
I also wonder why this can’t be provided as a new library on top of (rather than as a replacement for) the existing libDispatch C interface. I have my own DispatchQueue class that does a lot of what this proposal suggests but it doesn’t replace the dispatch_* calls so it doesn’t break anything. We are starting to accumulate a massive number of breaking changes. Yes there are fix-its but you still have problems with branches and coordinating the upgrade. I’m also sympathetic to the fact that any changes we want to make will only get more difficult with time and the longer we wait to refactor APIs, rename things, etc the less likely it will even be possible. I think part of the rush for these kinds of changes is the fact that Swift 3 wants to focus on ABI stability and a lot of people are interpreting that as “this is our last chance to fix everything we don’t like!”, though ABI stability != API stability. Might just be me though. Russ > On May 10, 2016, at 11:30 PM, Drew Crawford via swift-evolution > <swift-evolution@swift.org> wrote: > > I'm one of the largest dispatch-on-linux users right now. In fact, I'm > reasonably sure I'm THE largest. I have an application in production that > uses some 400 dispatch calls. > > 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. > > 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. > > 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. > > 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. > > 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. > > What we *should* be doing is creating libraries that *work*, *releasing > them*, and then we can do as much API Disneyland as we want without harassing > the working programmer. > > 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. > 2. If we're not out of bugs to fix, why not work on them, and then release, > and then come back to this? > 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. > > 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). > > 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. > > 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
