Draft update

References #494

Author: BasThomas

_drafts/2020-01-30-issue-152.md

@@ -0,0 +1,140 @@
+---
+layout: post
+title: ! 'Issue #152'
+author: btb
+sponsor:
+    link: TODO
+    heading: TODO
+    body: TODO
+    displaylink: TODO
+---
+
+> TODO: intro comments
+
+<!--excerpt-->
+
+{% include sponsor.html %}
+
+### Starter tasks
+
+> TODO
+
+### Podcasts
+
+> TODO: Latest episode(s) of Swift Unwrapped & the Swift Community Podcast
+
+### News and community
+
+[Ted Kremenek](https://twitter.com/tkremenek) shared [an update](https://forums.swift.org/t/on-the-road-to-swift-6/32862)
+on the road to Swift 6, with many interesting insights. If there's one thing
+you're going to pick up from this issue, it should be this — it's a great read.
+Some things mentioned:
+
+- Faster builds
+- More informative and accurate diagnostics
+- Reliable and fluid debugging experience
+- Provide excellent solutions for major language features such as memory
+ownership and concurrency
+- Significantly improve the performance of incremental builds
+- Improve code completion performance, reliability, and experience
+
+Like I said; you're going to want to give this a read.
+
+[JP Simard](https://twitter.com/simjp) created a poll [about the oldest Swift version people are actively using](https://twitter.com/simjp/status/1218613429881040897);
+a quite surprisingly high amount (to me) is pretty up-to-date with the latest
+Swift versions!
+
+[George Barnett](https://twitter.com/glbrntt) released [SwiftNIO 2.13.0](https://github.com/apple/swift-nio/releases/tag/2.13.0).
+
+### Commits and pull requests
+
+[Pavel Yaskevich](https://twitter.com/pyaskevich) merged [a pull request](https://github.com/apple/swift/pull/28837)
+that is a big step toward improving type inference for closures over time.
+
+### Accepted proposals
+
+> TODO
+
+### Returned proposals
+
+> TODO
+
+### Rejected proposals
+
+> TODO
+
+### Proposals in review
+
+[SE-0270](https://github.com/apple/swift-evolution/blob/master/proposals/0270-rangeset-and-collection-operations.md): *Add Collection Operations on Noncontiguous Elements* is [under a third review](https://forums.swift.org/t/se-0270-review-3-add-collection-operations-on-noncontiguous-elements/32839).
+
+> We can use a `Range<Index>` to refer to a group of consecutive positions in a
+collection, but the standard library doesn't currently provide a way to refer
+to discontiguous positions in an arbitrary collection. I propose the addition
+of a `RangeSet` type that can represent any number of positions, along with
+collection algorithms that operate on those positions.
+>
+> There are varied uses for tracking multiple elements in a collection, such as
+maintaining the selection in a list of items, or refining a filter or search
+result set after getting more input from a user.
+>
+> The Foundation data type most suited for this purpose, `IndexSet`, uses
+integers only, which limits its usefulness to arrays and other random-access
+collection types. The standard library is missing a collection that can
+efficiently store ranges of indices, and is missing the operations that you
+might want to perform with such a collection. These operations themselves can
+be challenging to implement correctly, and have performance traps as well — see
+last year's [Embracing Algorithms](https://developer.apple.com/videos/wwdc/2018/?id=223)
+WWDC talk for a demonstration.
+
+### Swift Forums
+
+[Frederick Kellison-Linn](https://twitter.com/jumhyn) pitched [a proposal](https://forums.swift.org/t/allow-chained-member-references-in-implicit-member-expressions/32829)
+to allow chained member references in implicit member expressions.
+
+> I propose that we extend implicit member syntax (a.k.a. "leading dot syntax")
+to allow for chained member references rather than just a single level.
+>
+> When the type of an expression is implied by the context, Swift allows
+developers to use what is formally referred to as an "implicit member
+expression", sometimes referred to as "leading dot syntax":
+
+```swift
+class C {
+    static let zero = C(0)
+    var x: Int
+
+    init(_ x: Int) {
+        self.x = x
+    }
+}
+
+func f(_ c: C) {
+    print(c.x)
+}
+
+f(.zero) // prints '0'
+```
+
+> However, attempting to use this with a chain of member references fails:
+
+```swift
+extension C {
+    var incremented: C {
+        return C(self.x + 1)
+    }
+}
+
+f(.zero.incremented) // Error: Type of expression is ambiguous without more context
+```
+
+> On master, the new diagnostic system has improved the produced error:
+
+```swift
+f(.zero.incremented) // Error: Cannot infer contextual base in reference to member 'zero'
+```
+
+> but the same problem persists.
+
+### Finally
+
+[#nofilter](https://twitter.com/jckarter/status/1217861938136276993).