End of source-breaking changes for Swift 3


(Ted Kremenek) #1

Dear friends,

Today is July 27 — and the last planned day to take source-breaking changes for Swift 3. It has been an incredible ride to this point, so let's take stock of where we are. Here are the list of currently accepted — but not yet (fully) implemented — evolution proposals (this is drawn from the "accepted" but not marked "implemented" proposals from the swift-evolution <https://github.com/apple/swift-evolution> repository):

SE-0025 - Scoped Access Level <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>
SE-0042 - Flattening the function type of unapplied method references <https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md>
SE-0045 - Add scan, prefix(while:), drop(while:), and iterate to the stdlib <https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md>
SE-0068 - Expanding Swift Self to class members and value types <https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>
SE-0075 - Adding a Build Configuration Import Test <https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md>
SE-0077 - Improved operator declarations <https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>
SE-0080 - Failable Numeric Conversion Initializers <https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md>
SE-0081 - Move where clause to end of declaration <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>
SE-0082 - Package Manager Editable Packages <https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md>
SE-0088 - Modernize libdispatch for Swift 3 naming conventions <https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>
SE-0089 - Renaming String.init<T>(_: T) <https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md>
SE-0092 - Typealiases in protocols and protocol extensions <https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md>
SE-0096 - Converting dynamicType from a property to an operator <https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md>
SE-0099 - Restructuring Condition Clauses <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>
SE-0101 - Reconfiguring sizeof and related functions into a unified MemoryLayout struct <https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md>
SE-0102 - Remove @noreturn attribute and introduce an empty Never type <https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md>
SE-0103 - Make non-escaping closures the default <https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>
SE-0104 - Protocol-oriented integers <https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>
SE-0107 - UnsafeRawPointer API <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>
SE-0110 - Distinguish between single-tuple and multiple-argument function types <https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md>
SE-0111 - Remove type system significance of function argument labels <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md>
SE-0120 - Revise partition Method Signature <https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md>
SE-0127 - Cleaning up stdlib Pointer and Buffer Routines <https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md>
These are all changes the community has approved for Swift but did not make today's cutoff. Some of these proposals have implementations actively underway. For those proposals already in active development — and near completion — I am okay with extending the deadline for those changes to Friday, July 29. Such changes need to be approved by the release manager (myself) and should be merged into master via a pull request. When creating the pull request, please assign it to me (tkremenek), and mention the pull request on the swift-dev mailing list as well with the SE number in the email title.

The rest of the unimplemented proposals do not make Swift 3. This leaves us with the question of what to do with them. These proposals represent the known and reviewed changes we want to make to Swift, but inevitably there will also be changes that we don't even know about today that we will want to take into Swift that can impact core source stability. That said, we also have a very strong desire to maintain source compatibility with Swift 3 and Swift 4 as much as possible to provide some stability for which Swift users to build upon. The challenge of course is reconciling these diametrically opposing goals: maintaining source stability while having the ability to incorporate more core (and important) language changes that are possibly source-breaking.

The Swift team at Apple has reflected on this and decided what it "means" for Swift 3 to be source compatible with Swift 4 and later releases going forward. Our goal is to allow app developers to combine a mix of Swift modules (e.g., SwiftPM packages), where each module is known to compile with a specific version of the language (module A works with Swift 3, module B works with Swift 3.1, etc.), then combine those modules into a single binary. The key feature is that a module can be migrated from Swift 3 to 3.1 to 4 (and beyond) independently of its dependencies.

While the exact details of how we will accomplish this feat are still being discussed, here is a sketch of how this will likely work in the Swift 4 timeframe. The key enabler is a new compiler flag that indicates the language version to compile for (e.g., similar to the clang -std=c99 flag). The compiler flag will be provided by the build system you are using (e.g., Xcode, SwiftPM, etc.) on a per-module basis:

For language syntax/semantics, the compiler can use the language mode to properly implement the language version being used by a module.

For the Standard Library, additive and subtractive changes are easily handled (the former by just adding them, the later by using deprecation techniques). For semantics changes, things are much more complicated, and will need further study.

The great thing about this approach is that a single Swift 4 compiler is building all of the sources in an application. This allows us to roll out this approach before achieving full ABI stability — something that will be a goal for Swift 4, but is impractical to achieve for a Swift 3.x release. It also provides us a general framework in the future for handling source compatibility as Swift evolves.

To make this more concrete, suppose an application is written to use Swift 4, but uses packages via SwiftPM that are written using Swift 3. A single compiler would build both the app and the packages — thus ensuring that all the compiled sources are binary compatible. It would not be the case that a framework built with the Swift 3 compiler could be used by an app built using the Swift 4 compiler. That kind of library binary stability (ABI) will be a key goal of the Swift 4 release.

These constraints mentioned above will serve as scaffolding for Swift 4 development. Discussion about Swift 4 commences on Monday. Ahead of that, Chris Lattner plans to send out thoughts from the Core team on some of the known key goals (and non-goals) for the release. In the meantime, the focus over the next couple days should be taking stock of what has landed for Swift 3 and to see if any of the proposals mentioned above are close to being completed or are truly out of scope.

Thank you again to everyone for making Swift 3 such as fantastic release!

Ted


(Slava Pestov) #2

These two are implemented. Should I prepare a PR to update the proposals?

Slava

···

On Jul 27, 2016, at 12:38 PM, Ted Kremenek via swift-dev <swift-dev@swift.org> wrote:

SE-0092 - Typealiases in protocols and protocol extensions <https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md>
SE-0102 - Remove @noreturn attribute and introduce an empty Never type <https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md>


(Jordan Rose) #3

Associating some proposals with their current implementers for the record…

···

On Jul 27, 2016, at 12:38, Ted Kremenek via swift-dev <swift-dev@swift.org> wrote:

Dear friends,

Today is July 27 — and the last planned day to take source-breaking changes for Swift 3. It has been an incredible ride to this point, so let's take stock of where we are. Here are the list of currently accepted — but not yet (fully) implemented — evolution proposals (this is drawn from the "accepted" but not marked "implemented" proposals from the swift-evolution <https://github.com/apple/swift-evolution> repository):

SE-0025 - Scoped Access Level <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>This one is nearly done (me).

SE-0077 - Improved operator declarations <https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>I believe this is what John’s working on at the moment.

SE-0081 - Move where clause to end of declaration <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>David was looking at this, but I’m not sure if it’s done.

SE-0088 - Modernize libdispatch for Swift 3 naming conventions <https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>I think we can call this done.

SE-0099 - Restructuring Condition Clauses <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>This is implemented; it’s just still marked as a warning rather than an error to use ‘where’.

SE-0103 - Make non-escaping closures the default <https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>MichaelI has been working on this.

SE-0107 - UnsafeRawPointer API <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>Andy has been working on this.

Jordan


(Jacob Bandes-Storch) #4

   - SE-0089 - Renaming String.init<T>(_: T)
   <https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md>

Has anyone worked on this? I have some time in the next couple of days and
might be able to come up with an implementation in time.


(Brent Royal-Gordon) #5

The associated bug, SR-1516, is assigned to Russ Bishop, who said in late June that he had the non-lazy versions implemented.

···

On Jul 27, 2016, at 12:38 PM, Ted Kremenek <kremenek@apple.com> wrote:

  • SE-0045 - Add scan, prefix(while:), drop(while:), and iterate to the stdlib

--
Brent Royal-Gordon
Architechies


(Tony Allevato) #6

I noticed that while SE-0091 appears to be implemented (from a cursory
glance at some of the affected types like Equatable and String), it looks
like the named methods are still part of the FloatingPoint protocol and
they still use global operators.

Is anyone tracking the migration of that protocol (and possibly also the
new Integer protocols) to use the new operator technique? (I have to
apologize for not being able to update the proposal with another PR that
listed all those changes—my free time outside my day job has been
significantly reduced lately.)

···

On Wed, Jul 27, 2016 at 12:38 PM Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote:

Dear friends,

Today is July 27 — and the last planned day to take source-breaking
changes for Swift 3. It has been an incredible ride to this point, so let's
take stock of where we are. Here are the list of currently accepted — but
not yet (fully) implemented — evolution proposals (this is drawn from the
"accepted" but not marked "implemented" proposals from the swift-evolution
<https://github.com/apple/swift-evolution> repository):

   - SE-0025 - Scoped Access Level
   <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>
   - SE-0042 - Flattening the function type of unapplied method references
   <https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md>
   - SE-0045 - Add scan, prefix(while:), drop(while:), and iterate to the
   stdlib
   <https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md>
   - SE-0068 - Expanding Swift Self to class members and value types
   <https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>
   - SE-0075 - Adding a Build Configuration Import Test
   <https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md>
   - SE-0077 - Improved operator declarations
   <https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>
   - SE-0080 - Failable Numeric Conversion Initializers
   <https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md>
   - SE-0081 - Move where clause to end of declaration
   <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>
   - SE-0082 - Package Manager Editable Packages
   <https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md>
   - SE-0088 - Modernize libdispatch for Swift 3 naming conventions
   <https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>
   - SE-0089 - Renaming String.init<T>(_: T)
   <https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md>
   - SE-0092 - Typealiases in protocols and protocol extensions
   <https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md>
   - SE-0096 - Converting dynamicType from a property to an operator
   <https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md>
   - SE-0099 - Restructuring Condition Clauses
   <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>
   - SE-0101 - Reconfiguring sizeof and related functions into a unified
   MemoryLayout struct
   <https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md>
   - SE-0102 - Remove @noreturn attribute and introduce an empty Never
    type
   <https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md>
   - SE-0103 - Make non-escaping closures the default
   <https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>
   - SE-0104 - Protocol-oriented integers
   <https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>
   - SE-0107 - UnsafeRawPointer API
   <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>
   - SE-0110 - Distinguish between single-tuple and multiple-argument
   function types
   <https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md>
   - SE-0111 - Remove type system significance of function argument labels
   <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md>
   - SE-0120 - Revise partition Method Signature
   <https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md>
   - SE-0127 - Cleaning up stdlib Pointer and Buffer Routines
   <https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md>

These are all changes the community has approved for Swift but did not
make today's cutoff. Some of these proposals have implementations actively
underway. For those proposals already in active development — *and near
completion* — I am okay with extending the deadline for those changes to *Friday,
July 29*. Such changes need to be approved by the release manager
(myself) and should be merged into master via a pull request. When
creating the pull request, please assign it to me (tkremenek), and
mention the pull request on the swift-dev mailing list as well with the
SE number in the email title.

The rest of the unimplemented proposals do not make Swift 3. This leaves
us with the question of what to do with them. These proposals represent the
known and reviewed changes we want to make to Swift, but inevitably there
will *also* be changes that we don't even know about today that we will
want to take into Swift that can impact core source stability. That said,
we also have a very strong desire to maintain source compatibility with
Swift 3 and Swift 4 as much as possible to provide some stability for which
Swift users to build upon. The challenge of course is reconciling these
diametrically opposing goals: maintaining source stability while having the
ability to incorporate more core (and important) language changes that are
possibly source-breaking.

The Swift team at Apple has reflected on this and decided what it "means"
for Swift 3 to be source compatible with Swift 4 and later releases going
forward. Our goal is to allow app developers to combine a mix of Swift
modules (e.g., SwiftPM packages), where each module is known to compile
with a specific version of the language (module A works with Swift 3,
module B works with Swift 3.1, etc.), then combine those modules into a
single binary. The key feature is that a module can be migrated from Swift
3 to 3.1 to 4 (and beyond) independently of its dependencies.

While the exact details of how we will accomplish this feat are still
being discussed, here is a sketch of how this will likely work in the Swift
4 timeframe. The key enabler is a new compiler flag that indicates the
language version to compile for (e.g., similar to the clang -std=c99 flag).
The compiler flag will be provided by the build system you are using (e.g.,
Xcode, SwiftPM, etc.) on a per-module basis:

   -

   For language syntax/semantics, the compiler can use the language mode
   to properly implement the language version being used by a module.
   -

   For the Standard Library, additive and subtractive changes are easily
   handled (the former by just adding them, the later by using deprecation
   techniques). For semantics changes, things are much more complicated, and
   will need further study.

The great thing about this approach is that a single Swift 4 compiler is
building all of the sources in an application. This allows us to roll out
this approach before achieving full ABI stability — something that will be
a goal for Swift 4, but is impractical to achieve for a Swift 3.x release.
It also provides us a general framework in the future for handling source
compatibility as Swift evolves.

To make this more concrete, suppose an application is written to use Swift
4, but uses packages via SwiftPM that are written using Swift 3. A single
compiler would build both the app and the packages — thus ensuring that all
the compiled sources are binary compatible. It would not be the case that a
framework built with the Swift 3 compiler could be used by an app built
using the Swift 4 compiler. That kind of library binary stability (ABI)
will be a key goal of the Swift 4 release.

These constraints mentioned above will serve as scaffolding for Swift 4
development. Discussion about Swift 4 commences on Monday. Ahead of that,
Chris Lattner plans to send out thoughts from the Core team on some of the
known key goals (and non-goals) for the release. In the meantime, the focus
over the next couple days should be taking stock of what has landed for
Swift 3 and to see if any of the proposals mentioned above are close to
being completed or are truly out of scope.

Thank you again to everyone for making Swift 3 such as fantastic release!

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


(Karl) #7

SE-0104 - Protocol-oriented integers <https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>We used to have a prototype implementation of this, but it was removed (by mistake?) by @moiseev a couple of weeks ago:

https://github.com/apple/swift/commit/61d1c599e8c90fdc7cc28e0fb8116a1dec883582#diff-c90eac1269a3e588de06d5a8d1812c48

It would be a shame if it didn’t get in. I’d be happy to volunteer towards anything outstanding (tests, I’m guessing?)

Karl


(Chris Lattner) #8

<dropping swift-evolution-announce>

···

On Jul 27, 2016, at 12:45 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 27, 2016, at 12:38 PM, Ted Kremenek via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

SE-0092 - Typealiases in protocols and protocol extensions <https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md>
SE-0102 - Remove @noreturn attribute and introduce an empty Never type <https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md>

These two are implemented. Should I prepare a PR to update the proposals?

Yes, please.

-Chris


(Ewa Matejska) #9

Associating some proposals with their current implementers for the record…

Dear friends,

Today is July 27 — and the last planned day to take source-breaking changes for Swift 3. It has been an incredible ride to this point, so let's take stock of where we are. Here are the list of currently accepted — but not yet (fully) implemented — evolution proposals (this is drawn from the "accepted" but not marked "implemented" proposals from the swift-evolution <https://github.com/apple/swift-evolution> repository):

SE-0025 - Scoped Access Level <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>This one is nearly done (me).

SE-0077 - Improved operator declarations <https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>I believe this is what John’s working on at the moment.

According to John this is done.

SE-0081 - Move where clause to end of declaration <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>David was looking at this, but I’m not sure if it’s done.

According to David, this is done.

Thanks,
Ewa

···

On Jul 27, 2016, at 1:21 PM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:

On Jul 27, 2016, at 12:38, Ted Kremenek via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

SE-0088 - Modernize libdispatch for Swift 3 naming conventions <https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>I think we can call this done.

SE-0099 - Restructuring Condition Clauses <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>This is implemented; it’s just still marked as a warning rather than an error to use ‘where’.

SE-0103 - Make non-escaping closures the default <https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>MichaelI has been working on this.

SE-0107 - UnsafeRawPointer API <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>Andy has been working on this.

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


(Douglas Gregor) #10

Also:

SE-0111 - Remove type system significance of function argument labels <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md>
I’m working on this one. This proposal is in an unfortunate position: doing it requires major changes to the type checker and ASTs. If we don’t get it in Swift 3, it will be extremely hard to implement in a Swift 4 compiler that needs to provide backward compatibility for Swift 3 code.

Let’s just hope I get it done quick :wink:

SE-0110 - Distinguish between single-tuple and multiple-argument function types <https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md>
I’m sorta hoping this falls out of a complete implementation SE-0111, but we’ll see.

  - Doug

···

On Jul 27, 2016, at 1:21 PM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:

Associating some proposals with their current implementers for the record…

On Jul 27, 2016, at 12:38, Ted Kremenek via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Dear friends,

Today is July 27 — and the last planned day to take source-breaking changes for Swift 3. It has been an incredible ride to this point, so let's take stock of where we are. Here are the list of currently accepted — but not yet (fully) implemented — evolution proposals (this is drawn from the "accepted" but not marked "implemented" proposals from the swift-evolution <https://github.com/apple/swift-evolution> repository):

SE-0025 - Scoped Access Level <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>This one is nearly done (me).

SE-0077 - Improved operator declarations <https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>I believe this is what John’s working on at the moment.

SE-0081 - Move where clause to end of declaration <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>David was looking at this, but I’m not sure if it’s done.

SE-0088 - Modernize libdispatch for Swift 3 naming conventions <https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>I think we can call this done.

SE-0099 - Restructuring Condition Clauses <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>This is implemented; it’s just still marked as a warning rather than an error to use ‘where’.

SE-0103 - Make non-escaping closures the default <https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>MichaelI has been working on this.

SE-0107 - UnsafeRawPointer API <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>Andy has been working on this.


(Roman Levenstein) #11

SE-0130 - Replace repeating Character and UnicodeScalar forms of String.init <https://github.com/apple/swift-evolution/blob/master/proposals/0130-string-initializers-cleanup.md>

This one was implemented by me. It was committed yesterday.
And, BTW, it was not mentioned in the original list of proposals sent out by Ted.

SE-0127 - Cleaning up stdlib Pointer and Buffer Routines <https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md>
I’ve implemented the unsafeAddress(of:) part. It was committed yesterday.
Erik and Bob were working on other parts of it. I don’t know for sure if all sub-tasks are completed by now.

-Roman

···

On Jul 27, 2016, at 1:21 PM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:

Associating some proposals with their current implementers for the record…

On Jul 27, 2016, at 12:38, Ted Kremenek via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Dear friends,

Today is July 27 — and the last planned day to take source-breaking changes for Swift 3. It has been an incredible ride to this point, so let's take stock of where we are. Here are the list of currently accepted — but not yet (fully) implemented — evolution proposals (this is drawn from the "accepted" but not marked "implemented" proposals from the swift-evolution <https://github.com/apple/swift-evolution> repository):

SE-0025 - Scoped Access Level <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>This one is nearly done (me).

SE-0077 - Improved operator declarations <https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>I believe this is what John’s working on at the moment.

SE-0081 - Move where clause to end of declaration <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>David was looking at this, but I’m not sure if it’s done.

SE-0088 - Modernize libdispatch for Swift 3 naming conventions <https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>I think we can call this done.

SE-0099 - Restructuring Condition Clauses <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>This is implemented; it’s just still marked as a warning rather than an error to use ‘where’.

SE-0103 - Make non-escaping closures the default <https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>MichaelI has been working on this.

SE-0107 - UnsafeRawPointer API <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>Andy has been working on this.

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


(Andrew Trick) #12

I still need to land one major source-breaking for UnsafePointer conversion, along with a sweeping stdlib update. However, I can’t land those until I’ve updated corelibs and other repositories.

-Andy

···

On Jul 27, 2016, at 1:21 PM, Jordan Rose via swift-dev <swift-dev@swift.org> wrote:

SE-0107 - UnsafeRawPointer API <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>Andy has been working on this.


(Ted Kremenek) #13

- swift-evolution, swift-evolution-announce

Dave/Max: can you speak this?

···

On Jul 27, 2016, at 3:17 PM, Tony Allevato <allevato@google.com> wrote:

I noticed that while SE-0091 appears to be implemented (from a cursory glance at some of the affected types like Equatable and String), it looks like the named methods are still part of the FloatingPoint protocol and they still use global operators.

Is anyone tracking the migration of that protocol (and possibly also the new Integer protocols) to use the new operator technique? (I have to apologize for not being able to update the proposal with another PR that listed all those changes—my free time outside my day job has been significantly reduced lately.)

On Wed, Jul 27, 2016 at 12:38 PM Ted Kremenek via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Dear friends,

Today is July 27 — and the last planned day to take source-breaking changes for Swift 3. It has been an incredible ride to this point, so let's take stock of where we are. Here are the list of currently accepted — but not yet (fully) implemented — evolution proposals (this is drawn from the "accepted" but not marked "implemented" proposals from the swift-evolution <https://github.com/apple/swift-evolution> repository):

SE-0025 - Scoped Access Level <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>
SE-0042 - Flattening the function type of unapplied method references <https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md>
SE-0045 - Add scan, prefix(while:), drop(while:), and iterate to the stdlib <https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md>
SE-0068 - Expanding Swift Self to class members and value types <https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>
SE-0075 - Adding a Build Configuration Import Test <https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md>
SE-0077 - Improved operator declarations <https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>
SE-0080 - Failable Numeric Conversion Initializers <https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md>
SE-0081 - Move where clause to end of declaration <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>
SE-0082 - Package Manager Editable Packages <https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md>
SE-0088 - Modernize libdispatch for Swift 3 naming conventions <https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>
SE-0089 - Renaming String.init<T>(_: T) <https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md>
SE-0092 - Typealiases in protocols and protocol extensions <https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md>
SE-0096 - Converting dynamicType from a property to an operator <https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md>
SE-0099 - Restructuring Condition Clauses <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>
SE-0101 - Reconfiguring sizeof and related functions into a unified MemoryLayout struct <https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md>
SE-0102 - Remove @noreturn attribute and introduce an empty Never type <https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md>
SE-0103 - Make non-escaping closures the default <https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>
SE-0104 - Protocol-oriented integers <https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>
SE-0107 - UnsafeRawPointer API <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>
SE-0110 - Distinguish between single-tuple and multiple-argument function types <https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md>
SE-0111 - Remove type system significance of function argument labels <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md>
SE-0120 - Revise partition Method Signature <https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md>
SE-0127 - Cleaning up stdlib Pointer and Buffer Routines <https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md>
These are all changes the community has approved for Swift but did not make today's cutoff. Some of these proposals have implementations actively underway. For those proposals already in active development — and near completion — I am okay with extending the deadline for those changes to Friday, July 29. Such changes need to be approved by the release manager (myself) and should be merged into master via a pull request. When creating the pull request, please assign it to me (tkremenek), and mention the pull request on the swift-dev mailing list as well with the SE number in the email title.

The rest of the unimplemented proposals do not make Swift 3. This leaves us with the question of what to do with them. These proposals represent the known and reviewed changes we want to make to Swift, but inevitably there will also be changes that we don't even know about today that we will want to take into Swift that can impact core source stability. That said, we also have a very strong desire to maintain source compatibility with Swift 3 and Swift 4 as much as possible to provide some stability for which Swift users to build upon. The challenge of course is reconciling these diametrically opposing goals: maintaining source stability while having the ability to incorporate more core (and important) language changes that are possibly source-breaking.

The Swift team at Apple has reflected on this and decided what it "means" for Swift 3 to be source compatible with Swift 4 and later releases going forward. Our goal is to allow app developers to combine a mix of Swift modules (e.g., SwiftPM packages), where each module is known to compile with a specific version of the language (module A works with Swift 3, module B works with Swift 3.1, etc.), then combine those modules into a single binary. The key feature is that a module can be migrated from Swift 3 to 3.1 to 4 (and beyond) independently of its dependencies.

While the exact details of how we will accomplish this feat are still being discussed, here is a sketch of how this will likely work in the Swift 4 timeframe. The key enabler is a new compiler flag that indicates the language version to compile for (e.g., similar to the clang -std=c99 flag). The compiler flag will be provided by the build system you are using (e.g., Xcode, SwiftPM, etc.) on a per-module basis:

For language syntax/semantics, the compiler can use the language mode to properly implement the language version being used by a module.

For the Standard Library, additive and subtractive changes are easily handled (the former by just adding them, the later by using deprecation techniques). For semantics changes, things are much more complicated, and will need further study.

The great thing about this approach is that a single Swift 4 compiler is building all of the sources in an application. This allows us to roll out this approach before achieving full ABI stability — something that will be a goal for Swift 4, but is impractical to achieve for a Swift 3.x release. It also provides us a general framework in the future for handling source compatibility as Swift evolves.

To make this more concrete, suppose an application is written to use Swift 4, but uses packages via SwiftPM that are written using Swift 3. A single compiler would build both the app and the packages — thus ensuring that all the compiled sources are binary compatible. It would not be the case that a framework built with the Swift 3 compiler could be used by an app built using the Swift 4 compiler. That kind of library binary stability (ABI) will be a key goal of the Swift 4 release.

These constraints mentioned above will serve as scaffolding for Swift 4 development. Discussion about Swift 4 commences on Monday. Ahead of that, Chris Lattner plans to send out thoughts from the Core team on some of the known key goals (and non-goals) for the release. In the meantime, the focus over the next couple days should be taking stock of what has landed for Swift 3 and to see if any of the proposals mentioned above are close to being completed or are truly out of scope.

Thank you again to everyone for making Swift 3 such as fantastic release!

Ted

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #14

- swift-evolution, swift-evolution-announce

Dave/Max: can you speak this?

I noticed that while SE-0091 appears to be implemented (from a
cursory glance at some of the affected types like Equatable and
String), it looks like the named methods are still part of the
FloatingPoint protocol and they still use global operators.

Is anyone tracking the migration of that protocol (and possibly also
the new Integer protocols) to use the new operator technique? (I
have to apologize for not being able to update the proposal with
another PR that listed all those changes—my free time outside my day
job has been significantly reduced lately.)

I think we view those changes as implicitly approved along with SE-0091.
I was working on making them but we've run into bugs with the feature's
implementation during the migration. When those are straightened out,
we can move forward with that cleanup.

···

on Wed Jul 27 2016, Ted Kremenek <kremenek-AT-apple.com> wrote:

On Jul 27, 2016, at 3:17 PM, Tony Allevato <allevato@google.com> wrote:

On Wed, Jul 27, 2016 at 12:38 PM Ted Kremenek via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >> wrote:
Dear friends,

Today is July 27 — and the last planned day to take source-breaking
changes for Swift 3. It has been an incredible ride to this point,
so let's take stock of where we are. Here are the list of currently
accepted — but not yet (fully) implemented — evolution proposals
(this is drawn from the "accepted" but not marked "implemented"
proposals from the swift-evolution
<https://github.com/apple/swift-evolution> repository):

SE-0025 - Scoped Access Level
<https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>
SE-0042 - Flattening the function type of unapplied method
references
<https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md>
SE-0045 - Add scan, prefix(while:), drop(while:), and iterate to the
stdlib
<https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md>
SE-0068 - Expanding Swift Self to class members and value types
<https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>
SE-0075 - Adding a Build Configuration Import Test
<https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md>
SE-0077 - Improved operator declarations
<https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>
SE-0080 - Failable Numeric Conversion Initializers
<https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md>
SE-0081 - Move where clause to end of declaration
<https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>
SE-0082 - Package Manager Editable Packages
<https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md>
SE-0088 - Modernize libdispatch for Swift 3 naming conventions
<https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>
SE-0089 - Renaming String.init<T>(_: T)
<https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md>
SE-0092 - Typealiases in protocols and protocol extensions
<https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md>
SE-0096 - Converting dynamicType from a property to an operator
<https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md>
SE-0099 - Restructuring Condition Clauses
<https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>
SE-0101 - Reconfiguring sizeof and related functions into a
unified MemoryLayout struct
<https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md>
SE-0102 - Remove @noreturn attribute and introduce an
empty Never type
<https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md>
SE-0103 - Make non-escaping closures the default
<https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>
SE-0104 - Protocol-oriented integers
<https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>
SE-0107 - UnsafeRawPointer API
<https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>
SE-0110 - Distinguish between single-tuple and multiple-argument
function types
<https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md>
SE-0111 - Remove type system significance of function argument
labels
<https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md>
SE-0120 - Revise partition Method Signature
<https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md>
SE-0127 - Cleaning up stdlib Pointer and Buffer Routines
<https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md>
These are all changes the community has approved for Swift but did
not make today's cutoff. Some of these proposals have
implementations actively underway. For those proposals already in
active development — and near completion — I am okay with extending
the deadline for those changes to Friday, July 29. Such changes need
to be approved by the release manager (myself) and should be merged
into master via a pull request. When creating the pull request,
please assign it to me (tkremenek), and mention the pull request on
the swift-dev mailing list as well with the SE number in the email
title.

The rest of the unimplemented proposals do not make Swift 3. This
leaves us with the question of what to do with them. These proposals
represent the known and reviewed changes we want to make to Swift,
but inevitably there will also be changes that we don't even know
about today that we will want to take into Swift that can impact
core source stability. That said, we also have a very strong desire
to maintain source compatibility with Swift 3 and Swift 4 as much as
possible to provide some stability for which Swift users to build
upon. The challenge of course is reconciling these diametrically
opposing goals: maintaining source stability while having the
ability to incorporate more core (and important) language changes
that are possibly source-breaking.

The Swift team at Apple has reflected on this and decided what it
"means" for Swift 3 to be source compatible with Swift 4 and later
releases going forward. Our goal is to allow app developers to
combine a mix of Swift modules (e.g., SwiftPM packages), where each
module is known to compile with a specific version of the language
(module A works with Swift 3, module B works with Swift 3.1, etc.),
then combine those modules into a single binary. The key feature is
that a module can be migrated from Swift 3 to 3.1 to 4 (and beyond)
independently of its dependencies.

While the exact details of how we will accomplish this feat are
still being discussed, here is a sketch of how this will likely work
in the Swift 4 timeframe. The key enabler is a new compiler flag
that indicates the language version to compile for (e.g., similar to
the clang -std=c99 flag). The compiler flag will be provided by the
build system you are using (e.g., Xcode, SwiftPM, etc.) on a
per-module basis:

For language syntax/semantics, the compiler can use the language
mode to properly implement the language version being used by a
module.

For the Standard Library, additive and subtractive changes are
easily handled (the former by just adding them, the later by using
deprecation techniques). For semantics changes, things are much more
complicated, and will need further study.

The great thing about this approach is that a single Swift 4
compiler is building all of the sources in an application. This
allows us to roll out this approach before achieving full ABI
stability — something that will be a goal for Swift 4, but is
impractical to achieve for a Swift 3.x release. It also provides us
a general framework in the future for handling source compatibility
as Swift evolves.

To make this more concrete, suppose an application is written to use
Swift 4, but uses packages via SwiftPM that are written using Swift
3. A single compiler would build both the app and the packages —
thus ensuring that all the compiled sources are binary
compatible. It would not be the case that a framework built with the
Swift 3 compiler could be used by an app built using the Swift 4
compiler. That kind of library binary stability (ABI) will be a key
goal of the Swift 4 release.

These constraints mentioned above will serve as scaffolding for
Swift 4 development. Discussion about Swift 4 commences on
Monday. Ahead of that, Chris Lattner plans to send out thoughts from
the Core team on some of the known key goals (and non-goals) for the
release. In the meantime, the focus over the next couple days should
be taking stock of what has landed for Swift 3 and to see if any of
the proposals mentioned above are close to being completed or are
truly out of scope.

Thank you again to everyone for making Swift 3 such as fantastic release!

Ted

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave


(Ben Rimmington) #15

<https://github.com/apple/swift/pull/3574>

-- Ben

···

On 27 Jul 2016, at 21:52, Jacob Bandes-Storch wrote:

SE-0089 - Renaming String.init<T>(_: T) <https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md>

Has anyone worked on this? I have some time in the next couple of days and might be able to come up with an implementation in time.


(Karl) #16

SE-0104 - Protocol-oriented integers <https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>We used to have a prototype implementation of this, but it was removed (by mistake?) by @moiseev a couple of weeks ago:

https://github.com/apple/swift/commit/61d1c599e8c90fdc7cc28e0fb8116a1dec883582#diff-c90eac1269a3e588de06d5a8d1812c48

It would be a shame if it didn’t get in. I’d be happy to volunteer towards anything outstanding (tests, I’m guessing?)

Karl


(Tony Allevato) #17

> - swift-evolution, swift-evolution-announce
>
> Dave/Max: can you speak this?

>>
>> I noticed that while SE-0091 appears to be implemented (from a
>> cursory glance at some of the affected types like Equatable and
>> String), it looks like the named methods are still part of the
>> FloatingPoint protocol and they still use global operators.
>>
>> Is anyone tracking the migration of that protocol (and possibly also
>> the new Integer protocols) to use the new operator technique? (I
>> have to apologize for not being able to update the proposal with
>> another PR that listed all those changes—my free time outside my day
>> job has been significantly reduced lately.)

I think we view those changes as implicitly approved along with SE-0091.
I was working on making them but we've run into bugs with the feature's
implementation during the migration. When those are straightened out,
we can move forward with that cleanup.

That's good to hear. Thanks for confirming!

···

On Wed, Jul 27, 2016 at 3:58 PM Dave Abrahams <dabrahams@apple.com> wrote:

on Wed Jul 27 2016, Ted Kremenek <kremenek-AT-apple.com> wrote:
>> On Jul 27, 2016, at 3:17 PM, Tony Allevato <allevato@google.com> wrote:

>> On Wed, Jul 27, 2016 at 12:38 PM Ted Kremenek via swift-evolution > >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> > >> wrote:
>> Dear friends,
>>
>> Today is July 27 — and the last planned day to take source-breaking
>> changes for Swift 3. It has been an incredible ride to this point,
>> so let's take stock of where we are. Here are the list of currently
>> accepted — but not yet (fully) implemented — evolution proposals
>> (this is drawn from the "accepted" but not marked "implemented"
>> proposals from the swift-evolution
>> <https://github.com/apple/swift-evolution> repository):
>>
>> SE-0025 - Scoped Access Level
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md
>
>> SE-0042 - Flattening the function type of unapplied method
>> references
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md
>
>> SE-0045 - Add scan, prefix(while:), drop(while:), and iterate to the
>> stdlib
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md
>
>> SE-0068 - Expanding Swift Self to class members and value types
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md
>
>> SE-0075 - Adding a Build Configuration Import Test
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md
>
>> SE-0077 - Improved operator declarations
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md
>
>> SE-0080 - Failable Numeric Conversion Initializers
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md
>
>> SE-0081 - Move where clause to end of declaration
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
>
>> SE-0082 - Package Manager Editable Packages
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md
>
>> SE-0088 - Modernize libdispatch for Swift 3 naming conventions
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
>
>> SE-0089 - Renaming String.init<T>(_: T)
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md
>
>> SE-0092 - Typealiases in protocols and protocol extensions
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md
>
>> SE-0096 - Converting dynamicType from a property to an operator
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md
>
>> SE-0099 - Restructuring Condition Clauses
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md
>
>> SE-0101 - Reconfiguring sizeof and related functions into a
>> unified MemoryLayout struct
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md
>
>> SE-0102 - Remove @noreturn attribute and introduce an
>> empty Never type
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md
>
>> SE-0103 - Make non-escaping closures the default
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md
>
>> SE-0104 - Protocol-oriented integers
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>
>> SE-0107 - UnsafeRawPointer API
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
>
>> SE-0110 - Distinguish between single-tuple and multiple-argument
>> function types
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md
>
>> SE-0111 - Remove type system significance of function argument
>> labels
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md
>
>> SE-0120 - Revise partition Method Signature
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md
>
>> SE-0127 - Cleaning up stdlib Pointer and Buffer Routines
>> <
https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md
>
>> These are all changes the community has approved for Swift but did
>> not make today's cutoff. Some of these proposals have
>> implementations actively underway. For those proposals already in
>> active development — and near completion — I am okay with extending
>> the deadline for those changes to Friday, July 29. Such changes need
>> to be approved by the release manager (myself) and should be merged
>> into master via a pull request. When creating the pull request,
>> please assign it to me (tkremenek), and mention the pull request on
>> the swift-dev mailing list as well with the SE number in the email
>> title.
>>
>> The rest of the unimplemented proposals do not make Swift 3. This
>> leaves us with the question of what to do with them. These proposals
>> represent the known and reviewed changes we want to make to Swift,
>> but inevitably there will also be changes that we don't even know
>> about today that we will want to take into Swift that can impact
>> core source stability. That said, we also have a very strong desire
>> to maintain source compatibility with Swift 3 and Swift 4 as much as
>> possible to provide some stability for which Swift users to build
>> upon. The challenge of course is reconciling these diametrically
>> opposing goals: maintaining source stability while having the
>> ability to incorporate more core (and important) language changes
>> that are possibly source-breaking.
>>
>> The Swift team at Apple has reflected on this and decided what it
>> "means" for Swift 3 to be source compatible with Swift 4 and later
>> releases going forward. Our goal is to allow app developers to
>> combine a mix of Swift modules (e.g., SwiftPM packages), where each
>> module is known to compile with a specific version of the language
>> (module A works with Swift 3, module B works with Swift 3.1, etc.),
>> then combine those modules into a single binary. The key feature is
>> that a module can be migrated from Swift 3 to 3.1 to 4 (and beyond)
>> independently of its dependencies.
>>
>> While the exact details of how we will accomplish this feat are
>> still being discussed, here is a sketch of how this will likely work
>> in the Swift 4 timeframe. The key enabler is a new compiler flag
>> that indicates the language version to compile for (e.g., similar to
>> the clang -std=c99 flag). The compiler flag will be provided by the
>> build system you are using (e.g., Xcode, SwiftPM, etc.) on a
>> per-module basis:
>>
>> For language syntax/semantics, the compiler can use the language
>> mode to properly implement the language version being used by a
>> module.
>>
>> For the Standard Library, additive and subtractive changes are
>> easily handled (the former by just adding them, the later by using
>> deprecation techniques). For semantics changes, things are much more
>> complicated, and will need further study.
>>
>> The great thing about this approach is that a single Swift 4
>> compiler is building all of the sources in an application. This
>> allows us to roll out this approach before achieving full ABI
>> stability — something that will be a goal for Swift 4, but is
>> impractical to achieve for a Swift 3.x release. It also provides us
>> a general framework in the future for handling source compatibility
>> as Swift evolves.
>>
>> To make this more concrete, suppose an application is written to use
>> Swift 4, but uses packages via SwiftPM that are written using Swift
>> 3. A single compiler would build both the app and the packages —
>> thus ensuring that all the compiled sources are binary
>> compatible. It would not be the case that a framework built with the
>> Swift 3 compiler could be used by an app built using the Swift 4
>> compiler. That kind of library binary stability (ABI) will be a key
>> goal of the Swift 4 release.
>>
>> These constraints mentioned above will serve as scaffolding for
>> Swift 4 development. Discussion about Swift 4 commences on
>> Monday. Ahead of that, Chris Lattner plans to send out thoughts from
>> the Core team on some of the known key goals (and non-goals) for the
>> release. In the meantime, the focus over the next couple days should
>> be taking stock of what has landed for Swift 3 and to see if any of
>> the proposals mentioned above are close to being completed or are
>> truly out of scope.
>>
>> Thank you again to everyone for making Swift 3 such as fantastic
release!
>>
>> Ted
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <
https://lists.swift.org/mailman/listinfo/swift-evolution>
>

--
-Dave


(Anton Zhilin) #18

https://github.com/apple/swift/commit/c8c41b385c0312e562abe4952fa2d6794dec2e0f
Is SE-0077 going to be implemented for Swift 3?

https://github.com/apple/swift/blob/master/stdlib/internal/SwiftExperimental/SwiftExperimental.swift
Does this code actually run?

If so, I will add "implemented" to the proposal, plus I still haven't added
latest naming changes. ¯\_(ツ)_/¯

···

2016-07-28 1:17 GMT+03:00 Tony Allevato via swift-evolution < swift-evolution@swift.org>:

I noticed that while SE-0091 appears to be implemented (from a cursory
glance at some of the affected types like Equatable and String), it looks
like the named methods are still part of the FloatingPoint protocol and
they still use global operators.

Is anyone tracking the migration of that protocol (and possibly also the
new Integer protocols) to use the new operator technique? (I have to
apologize for not being able to update the proposal with another PR that
listed all those changes—my free time outside my day job has been
significantly reduced lately.)

On Wed, Jul 27, 2016 at 12:38 PM Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote:

Dear friends,

Today is July 27 — and the last planned day to take source-breaking
changes for Swift 3. It has been an incredible ride to this point, so let's
take stock of where we are. Here are the list of currently accepted — but
not yet (fully) implemented — evolution proposals (this is drawn from the
"accepted" but not marked "implemented" proposals from the
swift-evolution <https://github.com/apple/swift-evolution> repository):

   - SE-0025 - Scoped Access Level
   <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>
   - SE-0042 - Flattening the function type of unapplied method
   references
   <https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md>
   - SE-0045 - Add scan, prefix(while:), drop(while:), and iterate to
   the stdlib
   <https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md>
   - SE-0068 - Expanding Swift Self to class members and value types
   <https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>
   - SE-0075 - Adding a Build Configuration Import Test
   <https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md>
   - SE-0077 - Improved operator declarations
   <https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>
   - SE-0080 - Failable Numeric Conversion Initializers
   <https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md>
   - SE-0081 - Move where clause to end of declaration
   <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>
   - SE-0082 - Package Manager Editable Packages
   <https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md>
   - SE-0088 - Modernize libdispatch for Swift 3 naming conventions
   <https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>
   - SE-0089 - Renaming String.init<T>(_: T)
   <https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md>
   - SE-0092 - Typealiases in protocols and protocol extensions
   <https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md>
   - SE-0096 - Converting dynamicType from a property to an operator
   <https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md>
   - SE-0099 - Restructuring Condition Clauses
   <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>
   - SE-0101 - Reconfiguring sizeof and related functions into a unified
   MemoryLayout struct
   <https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md>
   - SE-0102 - Remove @noreturn attribute and introduce an empty Never
    type
   <https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md>
   - SE-0103 - Make non-escaping closures the default
   <https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>
   - SE-0104 - Protocol-oriented integers
   <https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>
   - SE-0107 - UnsafeRawPointer API
   <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>
   - SE-0110 - Distinguish between single-tuple and multiple-argument
   function types
   <https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md>
   - SE-0111 - Remove type system significance of function argument
   labels
   <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md>
   - SE-0120 - Revise partition Method Signature
   <https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md>
   - SE-0127 - Cleaning up stdlib Pointer and Buffer Routines
   <https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md>

These are all changes the community has approved for Swift but did not
make today's cutoff. Some of these proposals have implementations actively
underway. For those proposals already in active development — *and near
completion* — I am okay with extending the deadline for those changes to *Friday,
July 29*. Such changes need to be approved by the release manager
(myself) and should be merged into master via a pull request. When
creating the pull request, please assign it to me (tkremenek), and
mention the pull request on the swift-dev mailing list as well with the
SE number in the email title.

The rest of the unimplemented proposals do not make Swift 3. This leaves
us with the question of what to do with them. These proposals represent the
known and reviewed changes we want to make to Swift, but inevitably there
will *also* be changes that we don't even know about today that we will
want to take into Swift that can impact core source stability. That said,
we also have a very strong desire to maintain source compatibility with
Swift 3 and Swift 4 as much as possible to provide some stability for which
Swift users to build upon. The challenge of course is reconciling these
diametrically opposing goals: maintaining source stability while having the
ability to incorporate more core (and important) language changes that are
possibly source-breaking.

The Swift team at Apple has reflected on this and decided what it "means"
for Swift 3 to be source compatible with Swift 4 and later releases going
forward. Our goal is to allow app developers to combine a mix of Swift
modules (e.g., SwiftPM packages), where each module is known to compile
with a specific version of the language (module A works with Swift 3,
module B works with Swift 3.1, etc.), then combine those modules into a
single binary. The key feature is that a module can be migrated from Swift
3 to 3.1 to 4 (and beyond) independently of its dependencies.

While the exact details of how we will accomplish this feat are still
being discussed, here is a sketch of how this will likely work in the Swift
4 timeframe. The key enabler is a new compiler flag that indicates the
language version to compile for (e.g., similar to the clang -std=c99 flag).
The compiler flag will be provided by the build system you are using (e.g.,
Xcode, SwiftPM, etc.) on a per-module basis:

   -

   For language syntax/semantics, the compiler can use the language mode
   to properly implement the language version being used by a module.
   -

   For the Standard Library, additive and subtractive changes are easily
   handled (the former by just adding them, the later by using deprecation
   techniques). For semantics changes, things are much more complicated, and
   will need further study.

The great thing about this approach is that a single Swift 4 compiler is
building all of the sources in an application. This allows us to roll out
this approach before achieving full ABI stability — something that will be
a goal for Swift 4, but is impractical to achieve for a Swift 3.x release.
It also provides us a general framework in the future for handling source
compatibility as Swift evolves.

To make this more concrete, suppose an application is written to use
Swift 4, but uses packages via SwiftPM that are written using Swift 3. A
single compiler would build both the app and the packages — thus ensuring
that all the compiled sources are binary compatible. It would not be the
case that a framework built with the Swift 3 compiler could be used by an
app built using the Swift 4 compiler. That kind of library binary stability
(ABI) will be a key goal of the Swift 4 release.

These constraints mentioned above will serve as scaffolding for Swift 4
development. Discussion about Swift 4 commences on Monday. Ahead of that,
Chris Lattner plans to send out thoughts from the Core team on some of the
known key goals (and non-goals) for the release. In the meantime, the focus
over the next couple days should be taking stock of what has landed for
Swift 3 and to see if any of the proposals mentioned above are close to
being completed or are truly out of scope.

Thank you again to everyone for making Swift 3 such as fantastic release!

Ted
_______________________________________________
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


(Ted Kremenek) #19

Please also update proposals.xml.

···

On Jul 27, 2016, at 12:50 PM, Chris Lattner <clattner@apple.com> wrote:

<dropping swift-evolution-announce>

On Jul 27, 2016, at 12:45 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jul 27, 2016, at 12:38 PM, Ted Kremenek via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

SE-0092 - Typealiases in protocols and protocol extensions <https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md>
SE-0102 - Remove @noreturn attribute and introduce an empty Never type <https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md>

These two are implemented. Should I prepare a PR to update the proposals?

Yes, please.

-Chris


(Erik Eckstein) #20

SE-0130 - Replace repeating Character and UnicodeScalar forms of String.init <https://github.com/apple/swift-evolution/blob/master/proposals/0130-string-initializers-cleanup.md>

This one was implemented by me. It was committed yesterday.
And, BTW, it was not mentioned in the original list of proposals sent out by Ted.

SE-0127 - Cleaning up stdlib Pointer and Buffer Routines <https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md>
I’ve implemented the unsafeAddress(of:) part. It was committed yesterday.
Erik and Bob were working on other parts of it. I don’t know for sure if all sub-tasks are completed by now.

I think that all tasks of SE-0127 are completed. Bob merged all PR related to the other 3 parts yesterday.

···

On Jul 27, 2016, at 2:01 PM, Roman Levenstein <rlevenstein@apple.com> wrote:

-Roman

On Jul 27, 2016, at 1:21 PM, Jordan Rose via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Associating some proposals with their current implementers for the record…

On Jul 27, 2016, at 12:38, Ted Kremenek via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Dear friends,

Today is July 27 — and the last planned day to take source-breaking changes for Swift 3. It has been an incredible ride to this point, so let's take stock of where we are. Here are the list of currently accepted — but not yet (fully) implemented — evolution proposals (this is drawn from the "accepted" but not marked "implemented" proposals from the swift-evolution <https://github.com/apple/swift-evolution> repository):

SE-0025 - Scoped Access Level <https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md>This one is nearly done (me).

SE-0077 - Improved operator declarations <https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md>I believe this is what John’s working on at the moment.

SE-0081 - Move where clause to end of declaration <https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md>David was looking at this, but I’m not sure if it’s done.

SE-0088 - Modernize libdispatch for Swift 3 naming conventions <https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>I think we can call this done.

SE-0099 - Restructuring Condition Clauses <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>This is implemented; it’s just still marked as a warning rather than an error to use ‘where’.

SE-0103 - Make non-escaping closures the default <https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md>MichaelI has been working on this.

SE-0107 - UnsafeRawPointer API <https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md>Andy has been working on this.

Jordan
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev