- swift-evolution, swift-evolution-announce Dave/Max: can you speak this?
> On Jul 27, 2016, at 3:17 PM, Tony Allevato <allev...@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-evolut...@swift.org <mailto:swift-evolut...@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-evolut...@swift.org <mailto:swift-evolut...@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
