<commit_before>---
layout: post
title: ! 'Issue #38'
author: jpsim
---

> TODO: intro comments, probably mention iOS 10 launch

<!--excerpt-->

### Starter tasks

The Swift team uses a Python script named `cmpcodesize` to measure the size of Swift build products. Improving that script is one way to contribute to reducing the size of Swift code. If you know some Python, try these tasks:

- [SR-407](https://bugs.swift.org/browse/SR-407): `cmpcodesize` is capable of analyzing the size and segments of macOS Mach-O build products. Complete this task to allow it to analyze code size on Linux, by supporting the ELF object format.
- [SR-2595](https://bugs.swift.org/browse/SR-2595): The current output format for `cmpcodesize` can't be easily parsed by other programs, making it hard to measure code size improvements and regressions over time. This task tracks adding additional output formats to `cmpcodesize`, such as CSV.

{% include task_remind.html %}

### Commits and pull requests

<NAME> [refactored](https://github.com/apple/swift/pull/4706) around 3000 lines of code, reducing the code browsing burden of the ClangImporter.

The one and only <NAME>s has been at work [separating withdrawn proposals from rejected ones](https://github.com/apple/swift-evolution/pull/526).

### Accepted proposals

TODO:

0139 accepted
https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000283.html

0140 accepted
https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000284.html

### Proposals in review
<commit_msg>[38] Add accepted proposals 0139 & 0140 (#87)<commit_after>---
layout: post
title: ! 'Issue #38'
author: jpsim
---

> TODO: intro comments, probably mention iOS 10 launch

<!--excerpt-->

### Starter tasks

The Swift team uses a Python script named `cmpcodesize` to measure the size of Swift build products. Improving that script is one way to contribute to reducing the size of Swift code. If you know some Python, try these tasks:

- [SR-407](https://bugs.swift.org/browse/SR-407): `cmpcodesize` is capable of analyzing the size and segments of macOS Mach-O build products. Complete this task to allow it to analyze code size on Linux, by supporting the ELF object format.
- [SR-2595](https://bugs.swift.org/browse/SR-2595): The current output format for `cmpcodesize` can't be easily parsed by other programs, making it hard to measure code size improvements and regressions over time. This task tracks adding additional output formats to `cmpcodesize`, such as CSV.

{% include task_remind.html %}

### Commits and pull requests

<NAME> [refactored](https://github.com/apple/swift/pull/4706) around 3000 lines of code, reducing the code browsing burden of the ClangImporter.

The one and only <NAME> has been at work [separating withdrawn proposals from rejected ones](https://github.com/apple/swift-evolution/pull/526).

### Accepted proposals

TODO:

<NAME>'s proposal, [SE-0139](https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md): *Bridge Numeric Types to `NSNumber` and Cocoa Structs to `NSValue`*, was [accepted with modifications](https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000283.html).

> The proposal has been accepted with one modification: numeric values bridged to `NSNumber` will maintain their type identity (e.g., an `Int8` bridged to an `NSNumber` can be cast via `as!`/`as?` to an `Int8`) while other instances of `NSNumber` (e.g., those created in Objective-C) can be cast to any numeric type that can represent their value. This matches the existing bridging behavior introduced in id-to-Any bridging ([SE-0116](https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md)). The proposal text has been updated accordingly.

<NAME>'s other proposal, [SE-0140](https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md): *Warn when `Optional` converts to `Any`, and bridge `Optional` As Its Payload Or `NSNull`*, was [accepted with one modification](https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000284.html).

> The proposal is accepted with one modification (described below).
> 
> Reviews on this proposal were mixed, with many expressing significant concerns about the ability to place an optional value into an `Any`, particularly when the `Any` comes from a nonnull-annotated Objective-C API:

{% highlight objective-c %}// Objective-C
@interface MyClass : NSObject
- (void)doSomething:(nonnull id)object;
@end{% endhighlight %}

{% highlight swift %}// Swift
let stringOpt: String? = getSomeString()
MyClass().doSomething(stringOpt)  // allowed; likely a programmer error{% endhighlight %}

> This behavior was introduced as part of id-as-Any bridging ([SE-0116](https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md))). As an amendment to SE-0140, Swift will produce a warning when an optional value is converted to a value of type `Any`, e.g.,

{% highlight swift %}MyClass().doSomething(stringOpt)  	// warning: optional value of type ‘String?’ is converted to an ‘Any’
					  				// note: use ‘!’ to force-unwrap the optional
					  				// note: use ‘??’ to provide a default value if the optional is nil
					  				// note: use ‘as Any’ to silence this warning{% endhighlight %}

> Such a warning will address most accidental injections of optional values into `Any`, and the core team felt that this addresses accidental boxing of optional values better than leaving the opaque object types to fail fast in Objective-C code that inspects them (e.g., see [this](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160905/026961.html) message for a negative review partly on these grounds).
> 
> To the main point of this proposal, which is to bridging to either the payload or `NSNull`, the core team felt that:
> 
> 1) Bridging to the payload or `NSNull` brings to Objective-C code the same behavior that is already present in Swift’s type system, where an optional containing a payload can be dynamically casted to its payload type. For example, this is well-formed in Swift:

{% highlight swift %}let optString: String? = "hello"
let anyValue: Any = optString
let stringValue: String = any as! stringValue   // downcast succeeds, produces a String{% endhighlight %}

> 2) While `NSNull` is not widely used in Cocoa APIs, it is better to enable those APIs to work properly when `nil` optional values do get bridged than to have an opaque-to-Objective-C boxed type that does not work well with any Objective-C APIs.

### Proposals in review

{'fraction_non_alphanumeric': 0.10039192041000905, 'fraction_numerical': 0.025927042508290626, 'mean_word_length': 4.4654036243822075, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 24, 'https://': 17, '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': '99097', 'n_tokens_mistral': 2087, 'n_tokens_neox': 1813, 'n_words': 792}