[swift-evolution] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

David Hart david at hartbit.com
Wed May 11 06:34:13 CDT 2016

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160511/5a74891b/attachment.html>

More information about the swift-evolution mailing list