<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jul 28, 2016, at 4:15 AM, Anton Zhilin <<a href="mailto:antonyzhilin@gmail.com" class="">antonyzhilin@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><a href="https://github.com/apple/swift/commit/c8c41b385c0312e562abe4952fa2d6794dec2e0f" class="">https://github.com/apple/swift/commit/c8c41b385c0312e562abe4952fa2d6794dec2e0f</a><br class=""></div>Is SE-0077 going to be implemented for Swift 3?</div></div></blockquote><div><br class=""></div>It's been implemented.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><a href="https://github.com/apple/swift/blob/master/stdlib/internal/SwiftExperimental/SwiftExperimental.swift" class="">https://github.com/apple/swift/blob/master/stdlib/internal/SwiftExperimental/SwiftExperimental.swift</a><br class=""></div><div class="">Does this code actually run?</div></div></div></blockquote><div><br class=""></div>Well, it's just a bunch of declarations, but I suppose technically it "runs", yes. :)</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">If so, I will add "implemented" to the proposal, plus I still haven't added latest naming changes. ¯\_(ツ)_/¯</div></div></div></blockquote><div><br class=""></div>Please revise to match the implementation. It's slightly different beyond just the naming changes, as noted in the commit:</div><div><br class=""></div><div> <a href="https://github.com/apple/swift/commit/c8c41b385c0312e562abe4952fa2d6794dec2e0f" class="">https://github.com/apple/swift/commit/c8c41b385c0312e562abe4952fa2d6794dec2e0f</a></div><div><br class=""></div><div>John.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-07-28 1:17 GMT+03:00 Tony Allevato via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">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.<div class=""><br class=""></div><div class="">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.)</div><div class=""><br class=""><br class=""><div class="gmail_quote"><div class=""><div class="gmail-h5"><div dir="ltr" class="">On Wed, Jul 27, 2016 at 12:38 PM Ted Kremenek via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class=""><div class="gmail-h5"><div style="word-wrap:break-word" class=""><p style="margin:0px 0px 15px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">Dear friends,</p><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">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 <a href="https://github.com/apple/swift-evolution" style="color:rgb(65,131,196)" target="_blank" class="">swift-evolution</a> repository):</p><ul style="margin:15px 0px;padding-left:30px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class=""><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0025 - Scoped Access Level</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0042 - Flattening the function type of unapplied method references</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0045 - Add scan, prefix(while:), drop(while:), and iterate to the stdlib</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0068 - Expanding Swift <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">Self</code> to class members and value types</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0075 - Adding a Build Configuration Import Test</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0077 - Improved operator declarations</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0080 - Failable Numeric Conversion Initializers</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0081 - Move <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">where</code> clause to end of declaration</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0082 - Package Manager Editable Packages</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0088 - Modernize libdispatch for Swift 3 naming conventions</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0089 - Renaming <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">String.init<T>(_: T)</code></a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0092 - Typealiases in protocols and protocol extensions</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0096 - Converting dynamicType from a property to an operator</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0099 - Restructuring Condition Clauses</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0101 - Reconfiguring <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">sizeof</code> and related functions into a unified <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">MemoryLayout</code> struct</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0102 - Remove <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">@noreturn</code> attribute and introduce an empty <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">Never</code> type</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0103 - Make non-escaping closures the default</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0104 - Protocol-oriented integers</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0107 - UnsafeRawPointer API</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0110 - Distinguish between single-tuple and multiple-argument function types</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0111 - Remove type system significance of function argument labels</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0120 - Revise <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">partition</code> Method Signature</a></li><li style="margin:0px" class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md" style="color:rgb(65,131,196);margin-top:0px" target="_blank" class="">SE-0127 - Cleaning up stdlib Pointer and Buffer Routines</a></li></ul><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">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 — <strong class="">and near completion</strong> — I am okay with extending the deadline for those changes to <strong class="">Friday, July 29</strong>. Such changes need to be approved by the release manager (myself) and should be merged into <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">master</code> via a pull request. When creating the pull request, please assign it to me (<code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">tkremenek</code>), and mention the pull request on the <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">swift-dev</code> mailing list as well with the SE number in the email title.</p><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">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 <em class="">also</em> 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.</p><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">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.</p><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">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 <code style="margin:0px 2px;padding:0px 5px;white-space:nowrap;border:1px solid rgb(234,234,234);border-radius:3px;background-color:rgb(248,248,248)" class="">-std=c99</code> flag). The compiler flag will be provided by the build system you are using (e.g., Xcode, SwiftPM, etc.) on a per-module basis:</p><ul style="margin:15px 0px;padding-left:30px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class=""><li style="margin:0px" class=""><p style="margin:0px 0px 15px" class="">For language syntax/semantics, the compiler can use the language mode to properly implement the language version being used by a module.</p></li><li style="margin:0px" class=""><p style="margin:0px 0px 15px" class="">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.</p></li></ul><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">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.</p><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">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.</p><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">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.</p><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">Thank you again to everyone for making Swift 3 such as fantastic release!</p><p style="margin:15px 0px;font-family:helvetica,arial,sans-serif;font-size:14px;background-color:rgb(255,255,255)" class="">Ted</p></div></div></div>_______________________________________________<span class="gmail-"><br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</span></blockquote></div></div></div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>