Issue 103 (#370)

* Initial issue 103 draft

* Finish draft

* Fix typos

* Update 2018-02-22-issue-103.md

* Move draft to posts

Author: BasThomas

_posts/2018-02-22-issue-103.md

@@ -0,0 +1,142 @@
+---
+layout: post
+title: ! 'Issue #103'
+author: btb
+---
+
+The last two weeks have brought us some exciting progress on Swift 5 and Xcode 9.3 (which brings us Swift 4.1). Regarding Xcode, we're now on [beta 3](https://download.developer.apple.com/Developer_Tools/Xcode_9.3_beta_3/Release_Notes_for_Xcode_9.3_beta_3.pdf).
+
+We can also expected some news on WWDC soon - last year, Apple announced WWDC on February 16th.
+
+That being said, I don't want to distract you from all the topics discussed in the newsletter. Thanks for reading!
+
+<!--excerpt-->
+
+### Swift Unwrapped
+
+[46: Restricting cross-module struct initializers](https://spec.fm/podcasts/swift-unwrapped/111543): Jesse and JP discuss the accepted [SE-0189](https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md) proposal, which makes structs less source-breaking.
+
+In [47: Revamping QuickLook Playground APIs](https://spec.fm/podcasts/swift-unwrapped/111551), they discuss [SE-0198](https://github.com/apple/swift-evolution/blob/master/proposals/0198-playground-quicklook-api-revamp.md) which, well, revamps the Quicklook Playground APIs.
+
+### News and community
+
+Ted Kremenek [announced](https://forums.swift.org/t/swift-to-participate-in-gsoc-2018/10147) that Swift will participate in Google Summer of Code this year!
+
+With Xcode 9.3 beta 3 came a new [tool for parsing code coverage output](https://twitter.com/SmileyKeith/status/966089848904810496), `xccov`.
+
+Erik Eckstein [wrote](https://swift.org/blog/osize/) a blog post on the official Swift.org blog on a new code size optimization mode in Swift 4.1. If you are already testing projects in Xcode 9.3, feel free to give this a try!
+
+Joe Groff [wrote](http://duriansoftware.com/joe/Optimizing-global-constant-data-structures-using-relative-references.html) a blog post on optimizing global constant data structures.
+
+Paul Hudson [gives on overview](https://www.hackingwithswift.com/articles/55/how-to-use-dynamic-member-lookup-in-swift) of what [SE-0195](https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md): *Introduce User-defined "Dynamic Member Lookup" Types* brings to the table to make Swift more dynamic.
+
+Keith Harrison [explains](https://useyourloaf.com/blog/replacing-flatmap-with-compactmap/) why one of `flatMap`'s implementations is now called `compactMap`, as per [SE-0187](https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md): *Introduce `Sequence.compactMap(_:)`*.
+
+Ben Cohen [gave a talk](https://www.dotconferences.com/2018/01/ben-cohen-extending-the-standard-library) on "Extending the Standard Library".
+
+Dave DeLong [wrote](https://davedelong.com/blog/2018/02/08/swift-protocols-wishlist/) a blog post about how he'd want to change how Swift deals with protocols.
+
+### Commits and pull requests
+
+Xiaodi Wu [merged](https://github.com/apple/swift/pull/14502) a pull request that improves the performance of floating-point constants after Jens Persson [discovered](http://forums.swift.org/t/is-floats-nextup-really-50-times-slower-than-necessary/9716) performance issues for `Float`s.
+
+Takeru Chuganji [merged](https://github.com/apple/swift/pull/13272) a pull request with an improvement to Swift diagnostics, offering fix-its to insert numeric conversions when needed.
+
+### Accepted proposals
+
+[SE-0195](https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md): *Introduce User-defined "Dynamic Member Lookup" Types* was [accepted](https://forums.swift.org/t/se-0195-introduce-user-defined-dynamic-member-lookup-types/8658/160).
+
+> On February 8 2018, the Core Team decided to accept this proposal.
+>
+> After reviewing the feedback from the community, the Core Team felt the spelling of the attribute should remain as proposed — `@dynamicMemberLookup`. The alternative of `@dynamic(...)` was also considered, but the Core Team felt that spelling to be too close to the dynamic keyword and a potential source of confusion.
+>
+> The rationale for the marker being an attribute instead of a protocol (as in the original proposal) was [well-articulated](https://forums.swift.org/t/se-0195-introduce-user-defined-dynamic-member-lookup-types/8658/159) by Chris Lattner in the review thread in that the marker protocol would not provide the expected affordances of a normal protocol.
+
+### Proposals in review
+
+[SE-0199](https://github.com/apple/swift-evolution/blob/master/proposals/0199-bool-toggle.md): *Adding `toggle` to `Bool`* is [under review](http://forums.swift.org/t/se-0199-adding-toggle-method-to-bool/9841).
+
+> For `Bool` variables, it is common to want to toggle the state of the variable. In larger (nested) structs, the duplication involved can become especially annoying:
+
+{% highlight swift %} 
+myVar.prop1.prop2.enabled = !myVar.prop1.prop2.enabled
+{% endhighlight %}
+
+> It's also easy to make a mistake in the code above if there are multiple `Bool` vars.
+> [The proposed solution is to] add a method toggle on `Bool`:
+
+{% highlight swift %}
+extension Bool {
+    mutating func toggle() {
+        self = !self
+    }
+}
+{% endhighlight %}
+
+> This allows us to write the example above without duplication:
+
+{% highlight swift %}
+myVar.prop1.prop2.enabled.toggle()
+{% endhighlight %}
+
+### Swift Forums
+
+Max Moiseev [pitched](https://forums.swift.org/t/proposal-to-improve-the-standard-library-stride-types/9675) a [proposal](https://github.com/moiseev/swift-evolution/blob/strides/proposals/0199-strides-revamp.md) to improve the Standard Library's `Stride` types.
+
+> With the addition of conditional conformances to the language, the result of `zip(_:_:)` can now be a `Collection` [if both containers being zipped conform to `Collection`](https://github.com/apple/swift/pull/13941).
+>
+> Unfortunately, without `StrideTo` conforming to `Collection` as proposed, expressions such as the following do not take advantage of zip’s conditional conformance.
+
+{% highlight swift %}
+zip([1,2,3], stride(from: 2, to: 42, by: 2))
+{% endhighlight %}
+
+> The result of this expression only conforms to `Sequence` and as such provides none of the `Collection` APIs.
+
+Daiki Matsudate [pitched](https://forums.swift.org/t/add-compactmapvalues-to-dictionary/8741) a [proposal](https://github.com/d-date/swift-evolution/blob/compact-map-values/proposals/0000-introduce-compact-map-values.md) to introduce `compactMapValue` to `Dictionary`.
+
+> This proposal adds a combined `filter`/`map` operation to `Dictionary`, as a companion to the `mapValues` and `filter` methods introduced by [SE-0165](https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md). The new `compactMapValues` operation corresponds to `compactMap` on `Sequence`.
+>
+> We sometimes need to transform and filter values of a `Dictionary` at the same time, and `Dictionary` does not currently provide an operation that directly supports this.
+
+Doug Gregor [pitched](https://forums.swift.org/t/c-interoperability-import-struct-incomplete-as-unsafe-mutable-rawpointer-rather-than-opaquepointer/9927)  a [proposal]() to replace `OpaquePointer`.
+
+> I propose to replace the `OpaquePointer` struct with a deprecated typealias for `UnsafeRawPointer`. Then, change the import of C pointers-to-incomplete-types to produce `UnsafeMutableRawPointer` or `UnsafeRawPointer`, depending on whether the pointee `const`.
+
+Doug also [pitched](https://forums.swift.org/t/objective-c-interoperability-eliminate-nsobjectprotocol/9947) eliminating `NSObjectProtocol`.
+
+> I propose to completely eliminate the `NSObject` protocol (called `NSObjectProtocol`) from Swift, leaving only a deprecated typealias (to `AnyObject`) as a backward-compatibility shim.
+
+Dave DeLong [pitched](https://forums.swift.org/t/supplement-file-line-and-function-with-context/9505) a proposal to add a `#context` keyword.
+
+> This would make it *much* easier to capture the context in which some code is executed rather than having to put `file: StaticString = #file, line: UInt = #line` parameters everywhere. A `context: Context = #context` would be much easier.
+
+Letanyan Arumugam [pitched](https://forums.swift.org/t/shorthand-for-offsetting-startindex-and-endindex/9397) a [proposal](https://github.com/Letanyan/swift-evolution/blob/offsetting-range-subscript/proposals/NNNN-offsetting-subscript.md) to introduce a shorthand for offsetting `startIndex` and `endIndex` in subscripts.
+
+> Using collection indexes are a bit of a bother when you want to do simple slicing and a type is not indexed by `Int`.
+>
+> For a simple example take the code here:
+
+{% highlight swift %}
+let s = "Hello, Swift"
+let m = s[...s.index(s.startIndex, offsetBy: 4)]
+{% endhighlight %}
+
+> The intent of advancing `startIndex` gets a bit muddled.
+>
+> So to ease this I think we could add `startIndex(offsetBy:)` and `endIndex(offsetBy:)` to `Collection`.
+>
+> Making the example above:
+
+{% highlight swift %}
+let s = "Hello, Swift"
+let m = s[...s.startIndex(offsetBy: 4)]
+{% endhighlight %}
+
+@tanner0101 [pitched](https://forums.swift.org/t/spm-static-dependencies/10152) a [proposal](https://github.com/tanner0101/swift-evolution/blob/spm-static-deps/proposals/NNNN-spm-static-deps.md) that adds support for static dependencies in the Swift Package Manager.
+
+> This proposal introduces the ability to rely on a dependency statically (meaning that it will be available for import in your `Package.swift` file). The idea is that this will greatly increase the usability and customization of the `Package.swift` file.
+
+### Finally
+
+The API does not work as expected? Can't be. Its unit tested and all. Did you [read its documentation](https://mobile.twitter.com/AirspeedSwift/status/962754808733036544)?