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

[Tony Allevato]

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

>
> on Wed Jul 27 2016, Ted Kremenek <kremenek-AT-apple.com> wrote:
>
> > - swift-evolution, swift-evolution-announce
> >
> > Dave/Max: can you speak this?
>
> >> On Jul 27, 2016, at 3:17 PM, Tony Allevato <allevato at 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.)
>
> 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 12:38 PM Ted Kremenek via swift-evolution
> >> <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
> >> https://lists.swift.org/mailman/listinfo/swift-evolution <
> https://lists.swift.org/mailman/listinfo/swift-evolution>
> >
>
> --
> -Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160727/c3756007/attachment.html>