<commit_before>---
layout: post
title: ! 'Issue #66'
author: gregheo
---

> TK Swift Weekly Brief limerick

<!--excerpt-->

{% include sponsor.html %}

### Starter tasks

> TODO

{% include task_remind.html %}

### Swift Unwrapped

Episode 7: [Access Control - The Saga Continues](https://spec.fm/podcasts/swift-unwrapped/65851)

In this week’s episode of _Swift Unwrapped_, your hosts Messrs. Simard and Squires discuss the rollercoaster that is the evolution of access control in Swift: where have we come from, where are we now, and where are we headed in the future? Tune in and become enlightened. 💡

### News and community

There’s already a new point release for [Brisk](https://github.com/br1sk/brisk), the delightful macOS app for submitting radars by [<NAME>](https://twitter.com/SmileyKeith).

And if you love radars so much, maybe you’re one of the chosen ones selected to try the shiny new [Bug Reporter beta](https://twitter.com/an0/status/854066062605897728)? It’s great to see Apple improving its communication channel for developers!


### Access Control Pitches

TK details

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035722.html

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035751.html

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035760.html

Although I had hoped this section could lead to a separate _Swift Access Control Discussion_ newsletter, it looks like that’s not in the cards:

> The core team considers the access-control matter closed for Swift 4 and will not be reviewing any further proposals in this area.

### Commits and pull requests

> TODO

### Accepted proposals

[SE-0169](https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md): _Improve Interaction Between `private` Declarations and Extensions_ was [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html).

Using the `private` keyword will now have a slightly wider scope: extensions to a type within the same file can now access private members.

> The core team feels that this proposal makes private access align more closely with the goals of the language:
> * It supports the notion that extensions are a code-organization tool: one should be able to break up a type’s definition into several extensions to improve the clarity of that code, without having to open up access or otherwise view the members in different extensions as completely-distinct entities. The core team expects future language evolution to reinforce the notion that extensions are more of a code organization tool than distinct entities, e.g., allowing stored properties to be introduced in an extension.
> * It makes private more usable as the default sub-internal access level, which supports progressive disclosure of the access control system and better matches with programmer’s expectations about what private access means.
> * It makes fileprivate more meaningful, because it is only needed for those cases where one is reaching across types (or among types and globals) within a file. It will also become more rare, which matches well with its longer, descriptive name.

> TODO

### Returned proposals

> TODO

### Rejected proposals

> TODO

### Proposals in review

[SE-0170](https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md): *NSNumber bridging and Numeric types* by <NAME> is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000351.html).

`NSNumber` is a very un-Swifty type: it rolls in all kinds of integer and floating point types into one big type. This proposal suggests ways to clean up the `NSNumber` bridging and handle underflow and overflow gracefully.

> `NSNumber` has been a strange duck in the Swift world especially when it has come to bridging and interacting with other protocols...`as?` for NSNumber should mean "Can I safely express the value stored in this opaque box called a `NSNumber` as the value I want?".

[SE-0171](https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md): *Reduce with `inout`* by <NAME> is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000352.html).

The `reduce` method passes along partial results to the next iteration, making copies each time. This proposal suggests adding a "reduce into" variant that uses an `inout` parameter instead to be more efficient in some cases:

> A new variant of `reduce` should be added to the standard library. Instead of taking a `combine` function that is of type `(A, Iterator.Element) -> A`, the full type and implementation of the added `reduce` will be:

{% highlight swift %}
extension Sequence {
    func reduce<A>(into initial: A, _ combine: (inout A, Iterator.Element) -> ()) -> A {
        var result = initial
        for element in self {
            combine(&result, element)
        }
        return result
    }
}
{% endhighlight %}

### Mailing lists

Since the mailing lists include folks from many countries and experience levels, it’s important to be precise on what you mean. Here’s a communications pro-tip from core team member <NAME>:

> [P]lease don't use the word “safe” this way around here as it
conflicts with the definition used by Swift. As defined by Swift, safety has nothing to do with whether something might trap or whether it's spelled with a "!", but about whether it can corrupt memory ([source](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035791.html))


> TODO

### Finally

> TODO: something funny/fun. tweet, link, etc.<commit_msg>[66] SE-0161, 0164 accepted, 0172 in review (#220)<commit_after>---
layout: post
title: ! 'Issue #66'
author: gregheo
---

> TK Swift Weekly Brief limerick

<!--excerpt-->

{% include sponsor.html %}

### Starter tasks

> TODO

{% include task_remind.html %}

### Swift Unwrapped

Episode 7: [Access Control - The Saga Continues](https://spec.fm/podcasts/swift-unwrapped/65851)

In this week’s episode of _Swift Unwrapped_, your hosts <NAME> Squires discuss the rollercoaster that is the evolution of access control in Swift: where have we come from, where are we now, and where are we headed in the future? Tune in and become enlightened. 💡

### News and community

There’s already a new point release for [Brisk](https://github.com/br1sk/brisk), the delightful macOS app for submitting radars by [<NAME>](https://twitter.com/SmileyKeith).

And if you love radars so much, maybe you’re one of the chosen ones selected to try the shiny new [Bug Reporter beta](https://twitter.com/an0/status/854066062605897728)? It’s great to see Apple improving its communication channel for developers!


### Access Control Pitches

TK details

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035722.html

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035751.html

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035760.html

Although I had hoped this section could lead to a separate _Swift Access Control Discussion_ newsletter, it looks like that’s not in the cards:

> The core team considers the access-control matter closed for Swift 4 and will not be reviewing any further proposals in this area.

### Commits and pull requests

> TODO

### Accepted proposals

[SE-0161](https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md): *Smart KeyPaths: Better Key-Value Coding for Swift* was [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000356.html).

> The [first review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html) established the main substance of the proposal, while the second review focused mostly on the more lightweight `\` syntax. The proposal is accepted with one clarification regarding the intersection between contextual keypaths (where the base type is left unspecified) and array types.
>
> The core team felt that the leading `\` is our best option for introducing keypaths. It is lightweight, yet provides a visual "escape" to indicate that the evaluation of the entities being referenced is being delayed. As noted in the result of the [first review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html), this is part of a longer-term plan to use the `\` for unapplied method references, bringing the two closely-related features into syntactic alignment over time and providing an opportunity to stage in the important but currently-source-breaking changes accepted in [SE-0042](https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md).
>
> Much discussion centered around potential ambiguities. Accessing a property of a key path, e.g., `\Person.friends[0].firstName.someKeyPathProperty`, requires one to parenthesize the key path as `(\Person.friends[0].firstName).someKeyPathProperty`,  which is a common way to disambiguate expressions in Swift (and most other programming languages) already. More concerning to the core team was the ambiguity between contextual keypaths starting with a `subscript` and keypaths rooted on an array type, e.g.,

{% highlight swift %}
\[a]?.foo     // is [a]? a type rooting a keypath “.foo”
              // or is it a contextual keypath starting with a subscript [a]?
{% endhighlight %}

> To resolve this ambiguity, *all* contextual keypaths will start with `\.`. The expression above will use the first interpretation (a type `[a]?` rooting a key path `.foo`), while the second interpretation would be written as:

{% highlight swift %}
\.[a]?.foo    // a contextual key path starting with the subscript [a]
{% endhighlight %}

> The core team felt that the result is more consistent: `\.` indicates a contextual keypath, while `\` without the `.` indicates a keypath with a specified root.
>
> The authors will revise the proposal according. Thank you to everyone who participated in the reviews of this much-anticipated feature!

[SE-0164](https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md): *Remove final support in protocol extensions* was [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000355.html).

> Feedback was light but positive, and the proposal is accepted.

[SE-0169](https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md): *Improve Interaction Between `private` Declarations and Extensions* was [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html).

Using the `private` keyword will now have a slightly wider scope: extensions to a type within the same file can now access private members.

> The core team feels that this proposal makes private access align more closely with the goals of the language:
> * It supports the notion that extensions are a code-organization tool: one should be able to break up a type’s definition into several extensions to improve the clarity of that code, without having to open up access or otherwise view the members in different extensions as completely-distinct entities. The core team expects future language evolution to reinforce the notion that extensions are more of a code organization tool than distinct entities, e.g., allowing stored properties to be introduced in an extension.
> * It makes private more usable as the default sub-internal access level, which supports progressive disclosure of the access control system and better matches with programmer’s expectations about what private access means.
> * It makes fileprivate more meaningful, because it is only needed for those cases where one is reaching across types (or among types and globals) within a file. It will also become more rare, which matches well with its longer, descriptive name.

> TODO

### Returned proposals

> TODO

### Rejected proposals

> TODO

### Proposals in review

[SE-0170](https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md): *NSNumber bridging and Numeric types* by <NAME> is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000351.html).

`NSNumber` is a very un-Swifty type: it rolls in all kinds of integer and floating point types into one big type. This proposal suggests ways to clean up the `NSNumber` bridging and handle underflow and overflow gracefully.

> `NSNumber` has been a strange duck in the Swift world especially when it has come to bridging and interacting with other protocols...`as?` for NSNumber should mean "Can I safely express the value stored in this opaque box called a `NSNumber` as the value I want?".

[SE-0171](https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md): *Reduce with `inout`* by <NAME> is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000352.html).

The `reduce` method passes along partial results to the next iteration, making copies each time. This proposal suggests adding a "reduce into" variant that uses an `inout` parameter instead to be more efficient in some cases:

> A new variant of `reduce` should be added to the standard library. Instead of taking a `combine` function that is of type `(A, Iterator.Element) -> A`, the full type and implementation of the added `reduce` will be:

{% highlight swift %}
extension Sequence {
    func reduce<A>(into initial: A, _ combine: (inout A, Iterator.Element) -> ()) -> A {
        var result = initial
        for element in self {
            combine(&result, element)
        }
        return result
    }
}
{% endhighlight %}

[SE-0172](https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md): *One-sided Ranges* by <NAME>, <NAME>, & <NAME> is [under review](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000358.html).

> This proposal introduces the concept of a "one-sided" range, created via prefix/postfix versions of the existing range operators.
>
> It also introduces a new protocol, `RangeExpression`, to simplify the creation of methods that take different kinds of ranges.
>
> [..]
>
> [The proposed solution is to] introduce a one-sided range syntax, where the "missing" side is inferred to be the start/end:

{% highlight swift %}
// half-open right-handed range
let greeting = s[..<i]
// closed right-handed range
let withComma = s[...i]
// left-handed range (no need for half-open variant)
let location = s[i...]
{% endhighlight %}

> [Continue reading...](https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md)

### Mailing lists

Since the mailing lists include folks from many countries and experience levels, it’s important to be precise on what you mean. Here’s a communications pro-tip from core team member <NAME>:

> [P]lease don't use the word “safe” this way around here as it
conflicts with the definition used by Swift. As defined by Swift, safety has nothing to do with whether something might trap or whether it's spelled with a "!", but about whether it can corrupt memory ([source](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035791.html))


> TODO

### Finally

> TODO: something funny/fun. tweet, link, etc.
{'fraction_non_alphanumeric': 0.09127343244990303, 'fraction_numerical': 0.02475759534583064, 'mean_word_length': 4.437961335676626, 'pattern_counts': {'":': 0, '<': 20, '<?xml version=': 0, '>': 75, 'https://': 38, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '219102', 'n_tokens_mistral': 4656, 'n_tokens_neox': 4099, 'n_words': 1820}