<commit_before>---
layout: post
title: ! 'Issue #17'
author: jsq
---

Welcome to issue #17! After all this time, the core team is still [just as encouraging](https://github.com/apple/swift/pull/2001#issuecomment-204765081) to contributors as it was on day one. It's really cool to see this. 😎

<!--excerpt-->

### Starter tasks

Suggestions from [<NAME>](https://github.com/SwiftWeekly/swiftweekly.github.io/issues/30):

- [SR-1124](https://bugs.swift.org/browse/SR-1124): Migrate legacy Swift stdlib tests to the StdlibUnittest framework. This would make those tests easier to read and maintain. Over the course of completing this task, newcomers to Swift development would become familiar with several tools used to test the compiler. There are 35 tests in total--feel free to claim individual tests by commenting on the task.

{% include task_remind.html %}

### Commits and pull requests

<NAME> [started work](https://github.com/apple/swift/pull/2001) on implementing proposal [SE-0046](https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md): *Establish consistent label behavior across all parameters including first labels*. ([SR-961](https://bugs.swift.org/browse/SR-961)) 👍 However, <NAME> [did too](https://github.com/apple/swift/pull/2047). 😳 It looks like everyone is collaborating on Manav's pull request now. Consider this a friendly reminder to remember to (1) assign JIRA tickets and (2) to check what's in-progress before starting work on a task. 😄

<NAME> submitted a [pull request](https://github.com/apple/swift-corelibs-foundation/pull/127) to corelibs-foundation that adds block and boolean `NSPredicate`s, `NSCompoundPredicate`, and an implementation of `NSArray.filteredArrayUsingPredicate`.

<NAME> opened a [pull request](https://github.com/apple/swift/pull/2002) for the new `Set` (Algebra) API changes.

<NAME> submitted a [pull request](https://github.com/apple/swift/pull/1994) to enable the `_ObjectiveCBridgeable` protocol on Linux, and opened a corresponding [pull request](https://github.com/apple/swift-corelibs-foundation/pull/303) on corelibs-foundation that implements basic usage of the `_ObjectiveCBridgeable` protocol on Linux. 🙌

<NAME> [merged](https://github.com/apple/swift/pull/1732) an implementation of [SE-0037](https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md): *Clarify interaction between comments & operators*, which resolves [SR-186](https://bugs.swift.org/browse/SR-186) and [SR-960](https://bugs.swift.org/browse/SR-960).

<NAME> submitted a [pull request](https://github.com/apple/swift-package-manager/pull/219) on swift-package-manager that adds the ability to auto-generate module map files for C libraries.

### Proposals

<NAME>'s proposal, [SE-0054](https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md): *Abolish `ImplicitlyUnwrappedOptional` type*, has been [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000084.html), **pending implementation**.

>There is generally positive feedback on the proposal, as it keeps the good behaviors of the existing `T!` type syntax (including support for importing un-nullability-audited APIs, support for 2-phase initialization patterns, etc) while dramatically reducing the confusion and surprise that they introduce as they trickle through type inference.  The core team sees significant value in having a simple and predictable model that can be explained concisely.
>
>That said, this is the sort of proposal that can have a profound impact on the actual experience using unaudited APIs.  The core team believes that the experience will be good, but we would like to get some experience moving a couple of existing projects (both low-level code that interacts with C, and an “App” project working with high level frameworks) to see what the impact is in practice.  If something unexpected comes up, we will revisit this, and potentially reject it later.  <NAME> is working on an implementation of this now, so we should know in the next week or two.

<NAME>'s proposal, [SE-0055](https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md): *Make unsafe pointer nullability explicit using Optional*, has been [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000086.html) **for Swift 3**.

>The community and core team overall agree that it is best to make the null pointer processing more consistent (by eliminating types that can be nil, but which are not Optional).  While UnsafePointer is disliked by many in the community, it is a necessary part of working with C APIs (as one prominent example).  Making them work consistently with other types makes the language simpler and more predictable.  This approach also dovetails well with the Clang nullability attributes, which allow auditing of C pointers.

### Mailing lists

> TODO:

### Finally

And finally &mdash; last Friday [<NAME>](https://twitter.com/modocache/status/715703413112176640) made Swift 9,000 times safer with one small [commit](https://github.com/modocache/swift/commit/e5ebd2e9d98eadb7bbddfcdbbf1a1064eb07a9f1). *"Force unwrapping is like totally unsafe."* 😂<commit_msg>drafts<commit_after>---
layout: post
title: ! 'Issue #17'
author: jsq
---

Welcome to issue #17! After all this time, the core team is still [just as encouraging](https://github.com/apple/swift/pull/2001#issuecomment-204765081) to contributors as it was on day one. It's really cool to see this. 😎 In other news, the [Swift 2.2.x milestone](https://github.com/apple/swift/milestones/Swift%202.2.x) accumulated more issues &mdash; only 2 open issues remaining for now.

<!--excerpt-->

### Starter tasks

Suggestions from [<NAME>](https://github.com/SwiftWeekly/swiftweekly.github.io/issues/30):

- [SR-1124](https://bugs.swift.org/browse/SR-1124): Migrate legacy Swift stdlib tests to the StdlibUnittest framework. This would make those tests easier to read and maintain. Over the course of completing this task, newcomers to Swift development would become familiar with several tools used to test the compiler. There are 35 tests in total--feel free to claim individual tests by commenting on the task.

{% include task_remind.html %}

### Commits and pull requests

<NAME> [started work](https://github.com/apple/swift/pull/2001) on implementing proposal [SE-0046](https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md): *Establish consistent label behavior across all parameters including first labels*. ([SR-961](https://bugs.swift.org/browse/SR-961)) 👍 However, <NAME> [did too](https://github.com/apple/swift/pull/2047). 😳 It looks like everyone is collaborating on Manav's pull request now. Consider this a friendly reminder to remember to (1) assign JIRA tickets and (2) to check what's in-progress before starting work on a task. 😄

<NAME> submitted a [pull request](https://github.com/apple/swift-corelibs-foundation/pull/127) to corelibs-foundation that adds block and boolean `NSPredicate`s, `NSCompoundPredicate`, and an implementation of `NSArray.filteredArrayUsingPredicate`.

<NAME> opened a [pull request](https://github.com/apple/swift/pull/2002) for the new `Set` (Algebra) API changes.

<NAME> submitted a [pull request](https://github.com/apple/swift/pull/1994) to enable the `_ObjectiveCBridgeable` protocol on Linux, and opened a corresponding [pull request](https://github.com/apple/swift-corelibs-foundation/pull/303) on corelibs-foundation that implements basic usage of the `_ObjectiveCBridgeable` protocol on Linux. 🙌

<NAME> [merged](https://github.com/apple/swift/pull/1732) an implementation of [SE-0037](https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md): *Clarify interaction between comments & operators*, which resolves [SR-186](https://bugs.swift.org/browse/SR-186) and [SR-960](https://bugs.swift.org/browse/SR-960).

<NAME> submitted a [pull request](https://github.com/apple/swift-package-manager/pull/219) on swift-package-manager that adds the ability to auto-generate module map files for C libraries.

### Proposals

<NAME>'s proposal, [SE-0054](https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md): *Abolish `ImplicitlyUnwrappedOptional` type*, has been [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000084.html), **pending implementation**.

>There is generally positive feedback on the proposal, as it keeps the good behaviors of the existing `T!` type syntax (including support for importing un-nullability-audited APIs, support for 2-phase initialization patterns, etc) while dramatically reducing the confusion and surprise that they introduce as they trickle through type inference.  The core team sees significant value in having a simple and predictable model that can be explained concisely.
>
>That said, this is the sort of proposal that can have a profound impact on the actual experience using unaudited APIs.  The core team believes that the experience will be good, but we would like to get some experience moving a couple of existing projects (both low-level code that interacts with C, and an “App” project working with high level frameworks) to see what the impact is in practice.  If something unexpected comes up, we will revisit this, and potentially reject it later.  <NAME> is working on an implementation of this now, so we should know in the next week or two.

Of course, another option would be to make Swift [9000x safer](https://twitter.com/modocache/status/715703413112176640) with this one small [commit](https://github.com/modocache/swift/commit/e5ebd2e9d98eadb7bbddfcdbbf1a1064eb07a9f1). 😂

<NAME>'s proposal, [SE-0055](https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md): *Make unsafe pointer nullability explicit using Optional*, has been [accepted](https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000086.html) **for Swift 3**.

>The community and core team overall agree that it is best to make the null pointer processing more consistent (by eliminating types that can be nil, but which are not Optional).  While UnsafePointer is disliked by many in the community, it is a necessary part of working with C APIs (as one prominent example).  Making them work consistently with other types makes the language simpler and more predictable.  This approach also dovetails well with the Clang nullability attributes, which allow auditing of C pointers.

### Mailing lists

> TODO:

### Finally

And finally &mdash; with all of the recent API transformations, guideline changes, and anticipation for Swift 3, you might be wondering [what's idiomatic Swift look like](https://twitter.com/harlanhaskins/status/717164997831307264)? *"You're supposed to put radar numbers above everything."* 😂
{'fraction_non_alphanumeric': 0.10138038211902367, 'fraction_numerical': 0.03327543651156413, 'mean_word_length': 5.024229074889868, 'pattern_counts': {'":': 0, '<': 28, '<?xml version=': 0, '>': 38, 'https://': 46, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4986208', 'n_tokens_mistral': 3384, 'n_tokens_neox': 2997, 'n_words': 1191}