I completely disagree with what you said. It sounds extreme to me to release a v1 of a library without giving yourself the flexibility to iterate on it beforehand.
> On 11 May 2016, at 08:30, 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
