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

[Xiaodi Wu]

On Wed, May 11, 2016 at 1:30 AM, 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.
>

FWIW, I believe the first Swift 3 preview branch is being created from
master tomorrow...


>
> 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/83adb384/attachment.html>