[swift-evolution] [swift-dev] Endgame for Swift 3

[Karl]

> On 15 Jul 2016, at 19:46, Ted Kremenek via swift-dev <swift-dev at swift.org> wrote:
> 
> Hi everyone,
> 
> Swift 3 has shaped up to be a remarkable release — a product of the inspiration, ideas, and hard labor many people from across the Swift open source community. It is now time, however, to talk about the endgame for the release.
> 
> Here are the key points:
> 
> The last day to take planned source-breaking changes for Swift 3 is July 27.
> 
> On that day, there will likely be a set of approved-but-not-implemented proposals for Swift 3 — including proposals for source-breaking changes. Will have an open discussion on that day on the fate of those unimplemented proposals in the context of Swift 3 and future Swift releases.
> 
> Starting on August 1 we will open up discussion about Swift 4. Part of this discussion will likely be guided by important work that was deferred from Swift 3, as well as the a goal of achieving binary stability in Swift 4. Until then, however, discussion should remain focused on Swift 3.
> 
> Note that there is an intentional gap of a few days between the last planned day to take source-breaking changes for Swift 3 and when we start talking about Swift 4. The idea is to provide some time for the community to take stock of where things have ended up for Swift 3.
> 
> The final branching plan for Swift 3 development is to be determined, but the final convergence branch is likely to be cut from master around that date or shortly after. Part of it comes down to the discussion on July 27 on how to handle the remaining unimplemented proposals for Swift 3.
> 
> The final release date for Swift 3 is TBD, but essentially after July 27 the intent is that Swift 3 is in full convergence and not in active development.
> 
> With these dates in mind, I want to call attention to some approved-but-not-yet-implemented proposals that currently I have nobody on Apple's Swift team able to tackle in the next couple weeks:
> 
> SE-0042: Flattening the function type of unapplied method references <https://github.com/apple/swift-evolution/tree/master/proposals/0042-flatten-method-types.md>
> SE-0068: Expanding Swift Self to class members and value types <https://github.com/apple/swift-evolution/tree/master/proposals/0068-universal-self.md>
> SE-0075: Adding a Build Configuration Import Test <https://github.com/apple/swift-evolution/tree/master/proposals/0075-import-test.md>
> SE-0096: Converting dynamicType from a property to an operator <https://github.com/apple/swift-evolution/tree/master/proposals/0096-dynamictype.md>
> SE-0077: Improved operator declarations <https://github.com/apple/swift-evolution/tree/master/proposals/0077-operator-precedence.md>
> SE-0092: Typealiases in protocols and protocol extensions <https://github.com/apple/swift-evolution/tree/master/proposals/0092-typealiases-in-protocols.md>
> SE-0110: Distinguish between single-tuple and multiple-argument function types <https://github.com/apple/swift-evolution/tree/master/proposals/0110-distingish-single-tuple-arg.md>
> Some proposals — like SE-0075 <https://github.com/apple/swift-evolution/tree/master/proposals/0075-import-test.md> — are things we can add at any time, but many of the others tie into the goal of achieving some degree of source-stability for Swift in Swift 3. I'm letting the community know that these proposals currently have no implementation traction in case there is interest in helping make them happen in time for Swift 3.
> 
> Related, I'd like to call out a special thanks to the community for getting implementation traction on SE-0095:
> 
> SE-0095: Replace protocol<P1,P2> syntax with P1 & P2 syntax <https://github.com/apple/swift-evolution/tree/master/proposals/0095-any-as-existential.md>
> Currently there is a JIRA issue <https://bugs.swift.org/browse/SR-1938> and pull request <https://github.com/apple/swift/pull/3293> tracking work on implementing this proposal.
> 
> In addition to these language proposals, there is also an assortment of outstanding work for the Standard Library that would be great to do for Swift 3. There is a gist summarizing those tasks:
> 
> https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d <https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d>
> These tasks are broken down in relative order of difficulty, with a JIRA issue associated with each one of them. If a JIRA isssue is currently not assigned to anyone, please consider them fair game to tackle if you are interested. API changes that have currently not gone through the evolution process will still need an evolution proposal, even if they are listed in the gist. If you take on a specific task, please assign the JIRA issue to yourself so others know it is being tackled.
> 
> Thank you to everyone — and I mean everyone — who has contributed to making Swift 3 happen.
> 
> Ted
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev


Oh, and one more thing - the new Dispatch API. I’m unhappy with some parts of it, and I’ve seen discussions on here before mine from people who were unhappy with the same parts (and more). The dispatch team have said they are planning changes, but I don’t think they’ll resolve the issue.

I think the proper thing to do would be to have another review about any changes the dispatch team are planning for Swift 3, so we have a chance to discuss it and come to some consensus. Perhaps for Foundation, too, if they are planning any late changes to the new API (I don’t know of any specifically)?

Karl


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160716/821b7ccc/attachment.html>