[swift-evolution] End of source-breaking changes for Swift 3

Thu Jul 28 10:34:20 CDT 2016

See the thread about stabilizing CI. The locked master while they worked
out issues with the CI systems. Last I read it should be unlocked soon.
On Thu, Jul 28, 2016 at 8:30 AM Brian Gesiak via swift-evolution <
swift-evolution at swift.org> wrote:

> Apologies if this was announced elsewhere: is commit access to master
> restricted?
>
> I noticed I couldn't merge some documentation improvements in
> https://github.com/apple/swift/pull/3815, and just wanted to make sure
> this was due to Swift 3 finalization.
>
> If commit access is restricted, is it safe to assume that restriction will
> be lifted on or around July 29?
>
>
> - Brian Gesiak
>
> On Thu, Jul 28, 2016 at 7:15 AM, Anton Zhilin via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> 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 at 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 at 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 at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160728/18c7c1a0/attachment.html>