Endgame for Swift 3

tkremenek · 2016-07-15T17:46:41.000Z

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 <Issues · apple/swift-issues · GitHub; 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:

gist.github.com

https://gist.github.com/gribozavr/37e811f12b27c6365fc88e6f9645634d

stdlib-api-stability-issues.md

Open Issues Affecting Standard Library API Stability
====================================================

This document lists the outstanding issues whose resolution could
cause non-additive standard library API changes.

Low-Hanging Fruit (Difficulty: 1)
---------------------------------------

* The global function `withUnsafe[Mutable]Pointer(&x)` should have an

This file has been truncated. show original

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

willft · 2016-07-15T18:18:03.000Z

Is there any way to tell which of the changes in the gist have had
proposals associated with them?

-- Will

···

On Fri, Jul 15, 2016 at 1:46 PM Ted Kremenek via swift-evolution < swift-evolution@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 <Issues · apple/swift-issues · GitHub;
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:

   - Open Issues Affecting Standard Library API Stability · GitHub

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

Karl · 2016-07-16T04:19:01.000Z

github.com

apple/swift-evolution/blob/main/proposals/0092-typealiases-in-protocols.md

# Typealiases in protocols and protocol extensions

* Proposal: [SE-0092](0092-typealiases-in-protocols.md)
* Authors: [David Hart](https://github.com/hartbit), [Doug Gregor](https://github.com/DougGregor)
* Review Manager: [Chris Lattner](http://github.com/lattner)
* Status: **Implemented (Swift 3)**
* Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0092-typealiases-in-protocols-and-protocol-extensions/2639)
* Bug: [SR-1539](https://bugs.swift.org/browse/SR-1539)

## Introduction

This proposal is from the [Generics Manifesto](https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md) and brings the `typealias` keyword back into protocols for type aliasing.

## Motivation

In Swift versions prior to 2.2, the `typealias` keyword was used outside of protocols to declare type aliases and in protocols to declare associated types. Since [SE-0011](0011-replace-typealias-associated.md) and Swift 2.2, associated type now use the `associatedtype` keyword and `typealias` is available for implementing true associated type aliases. 

## Proposed solution

The solution allows the creation of associated type aliases. Here is an example from the standard library:

This file has been truncated. show original

Isn't half of this done, or something? I seem to remember seeing code about it, and I think there may even be a hidden switch to enable what is there.

···

Sent from my new Email (‎Email - Edison Mail on the App Store)

On Jul 15, 2016 at 7:46 PM, <Ted Kremenek via swift-dev (mailto:swift-dev@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 (x-apple-data-detectors://1). (x-apple-data-detectors://1)

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 (x-apple-data-detectors://2)August 1 (x-apple-data-detectors://2) 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 (x-apple-data-detectors://3) 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 (x-apple-data-detectors://4) 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:

Open Issues Affecting Standard Library API Stability · GitHub

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@swift.org (mailto:swift-dev@swift.org) https://lists.swift.org/mailman/listinfo/swift-dev

Karl · 2016-07-16T11:34:30.000Z

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

···

On 15 Jul 2016, at 19:46, Ted Kremenek via swift-dev <swift-dev@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 <Issues · apple/swift-issues · GitHub; 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:

Open Issues Affecting Standard Library API Stability · GitHub
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

tkremenek · 2016-07-15T18:44:05.000Z

Good question.

Dave/Dmitri: do you have a recommendation here? I can see either the JIRA issues referencing the proposal (if one exists) or updating the gist. I prefer the former.

···

On Jul 15, 2016, at 11:18 AM, Will Field-Thompson <will.a.ft@gmail.com> wrote:

Is there any way to tell which of the changes in the gist have had proposals associated with them?

-- Will

On Fri, Jul 15, 2016 at 1:46 PM Ted Kremenek via swift-evolution <swift-evolution@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
SE-0068: Expanding Swift Self to class members and value types
SE-0075: Adding a Build Configuration Import Test
SE-0096: Converting dynamicType from a property to an operator
SE-0077: Improved operator declarations
SE-0092: Typealiases in protocols and protocol extensions
SE-0110: Distinguish between single-tuple and multiple-argument function types
Some proposals — like SE-0075 — 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
Currently there is a JIRA issue and pull request 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:

Open Issues Affecting Standard Library API Stability · GitHub
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-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

gribozavr · 2016-07-15T18:45:50.000Z

Updating the JIRA sounds good to me, too.

Dmitri

···

On Fri, Jul 15, 2016 at 11:44 AM, Ted kremenek via swift-dev <swift-dev@swift.org> wrote:

Good question.

Dave/Dmitri: do you have a recommendation here? I can see either the JIRA
issues referencing the proposal (if one exists) or updating the gist. I
prefer the former.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

dabrahams · 2016-07-15T22:02:27.000Z

SGTM

···

on Fri Jul 15 2016, Dmitri Gribenko <swift-evolution@swift.org> wrote:

On Fri, Jul 15, 2016 at 11:44 AM, Ted kremenek via swift-dev > <swift-dev@swift.org> wrote:

Good question.

Dave/Dmitri: do you have a recommendation here? I can see either the JIRA
issues referencing the proposal (if one exists) or updating the gist. I
prefer the former.

Updating the JIRA sounds good to me, too.

--
Dave

Patrick_Pijnappel · 2016-07-16T05:35:05.000Z

Isn't half of this done, or something? I seem to remember seeing code
about it, and I think there may even be a hidden switch to enable what is
there.

The parsing code seems to be in place, toggled by the flag Context.LangOpts.
EnableProtocolTypealiases:

github.com

apple/swift/blob/main/lib/Parse/ParseDecl.cpp#L2080


      
          }
          
          ParserStatus
          Parser::parseAvailabilityMacro(SmallVectorImpl<AvailabilitySpec *> &Specs) {
            // Get the macros from the compiler arguments.
            parseAllAvailabilityMacroArguments();
            AvailabilityMacroMap Map = AvailabilityMacros;
          
            StringRef MacroName = Tok.getText();
            auto NameMatch = Map.find(MacroName);
            if (NameMatch == Map.end())
              return makeParserSuccess(); // No match, it could be a standard platform.
          
            consumeToken();
          
            llvm::VersionTuple Version;
            SourceRange VersionRange;
            if (Tok.isAny(tok::integer_literal, tok::floating_literal)) {
              if (parseVersionTuple(Version, VersionRange,
                                    diag::avail_query_expected_version_number))
                return makeParserError();

Is this still blocked by support elsewhere?

···

On Sat, Jul 16, 2016 at 2:19 PM, Karl Wagner via swift-dev < swift-dev@swift.org> wrote:

https://github.com/apple/swift-evolution/tree/master/proposals/0092-typealiases-in-protocols.md

Isn't half of this done, or something? I seem to remember seeing code
about it, and I think there may even be a hidden switch to enable what is
there.

Sent from my new Email
<‎Email - Edison Mail on the App Store;

On Jul 15, 2016 at 7:46 PM, <Ted Kremenek via swift-dev > <swift-dev@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 <Issues · apple/swift-issues · GitHub;
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:

   - Open Issues Affecting Standard Library API Stability · GitHub

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

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Greg_Titus · 2016-07-16T06:53:07.000Z

With the EnableProtocolTypealiases flag turned on, some (most?) of this is done. You can see the tests in test/decl/typealias/protocol.swift along with the remaining FIXMEs. Slava has cleaned up my attempts at it. :-) The last commit (a09986f) in this area is him saying "This will be more generally useful once I fix a few more issues in name lookup”.

- Greg

···

On Jul 15, 2016, at 10:35 PM, Patrick Pijnappel via swift-dev <swift-dev@swift.org> wrote:

Isn't half of this done, or something? I seem to remember seeing code about it, and I think there may even be a hidden switch to enable what is there.

The parsing code seems to be in place, toggled by the flag Context.LangOpts.EnableProtocolTypealiases:
https://github.com/apple/swift/blob/master/lib/Parse/ParseDecl.cpp#L2080

Is this still blocked by support elsewhere?