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