2016-03-17

NSDecimalNumber(floatLiteral:)は使ってはいけない

私がSwiftで気に入っている改善として、NSDecimalNumberのインスタンスがちょう簡単に作れることがあります。

let d : NSDecimalNumber = 15.97

すばらしい。Objective Cだとこうなって、辛い。

NSDecimalNumber *d = [NSDecimalNumber decimalNumberWithString:@"15.97"];

このSwiftの機能はFloatLiteralConvertibleというプロトコルを使って実装されていて、floatのリテラルの型がFloatLiteralConvertibleなクラス（構造体もできる？）のときに、適当なイニシャライザを呼んで変換してくれるというものです。

init(floatLiteral: Double)

わーかっこいい。かっこいいのですが、ところがしかし型をよく見ると一回Doubleが作られています。NSDecimalNumberをDoubleから作るのは安全なのかと聞かれて、一瞬悩んでしまったのでした。とりあえず、NSDecimalNumberについて言えば明らかにダメです。

let d : NSDecimalNumber = 15.97
_ = d.stringValue     // => "15.970000000000004096"

15.97とは似ても似つかない値になりました。Stringから作る場合と見比べれば明らかですね。

let d = NSDecimalNumber(string: "15.97")
_ = d.stringValue     // => "15.97"

やはり、NSDecimalNumberを作るときには、整数か文字列を与えるのが安全なようです。

さて、これはなぜでしょう？「浮動小数点はそんなもんだよ」と言われて、一瞬納得してしまいそうになったのですが、やっぱりよく考えた結果、これはNSDecimalNumberが壊れているというのが私の現時点の理解です。

浮動小数点に関しては、僕は全然経験がないので、ここから先まったく間違ったことを言うかもしれません。自信はありません。間違っていたら、教えてもらえると嬉しいです。

Floatのリテラルとは

0.1を10回足しても1.0にならないことはよく知られていると思います。

let a = 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1 + 0.1
_ = (a as NSNumber).stringValue // => "0.9999999999999999"

ソースコードに0.1と書いても、それは実数の0.1ではありません。Doubleで表現できる中で一番実数の0.1に近い数です。この辺りの感覚があると、15.97が15.970000000000004096になると言われても納得しても良さそうな気がする感じもします。

ところが、0.1を一度Doubleにしてから文字列表現に直すと、"0.1"が得られます。0.1ではないのに。少し不思議な気がしますね。これは、Doubleを表現する10進数の中に0.1よりも近いものが他にないことが理由です（多分）。Floatから文字列への変換をどういうアルゴリズムで実装するかによって違いが生まれますが、SwiftとかNSNumberではそうなっているようです。Swiftで試すと、0.1に対応するFloatの文字列表現は"0.1"ですし、15.97に対応するFloatの文字列表現は"15.97"です。

FloatをNSDecimalNumberに変換するというのは10進数に変換するのと同じことですから、NSDecimalNumberにDoubleを与えるとおかしくなるというのは辻褄が合わない話に思えます。

もちろん、変な数を考えるとうまく行かなくなることはあります。

let x = 0.09999999999999986
let y = 0.09999999999999987
_ x == y  // => true

ここで、xとyは区別できないので、文字列表現も元には戻りません。

_ = (x as NSNumber).stringValue   // => "0.09999999999999987"
_ = (y as NSNumber).stringValue   // => "0.09999999999999987"

まあ仕方ないですね。NSDecimalNumberにすればこの二つは区別できるようになります。

let x = NSDecimalNumber(string: "0.09999999999999986")
let y = NSDecimalNumber(string: "0.09999999999999987")

_ = x.stringValue   // => "0.09999999999999986"
_ = y.stringValue   // => "0.09999999999999987"

15.970000000000004096

それでは、15.970000000000004096とはなんなのでしょうか。15.97は15.970000000000004096だったのでしょうか。

let s = 15.97
let t = 15.970000000000004096
_ = s == t   // => false

もちろん違います。この二つは別々の数として認識されています。15.97と15.970000000000004096の間の数すら、Doubleは表現できます。

let u = (s + t)/2
_ = s < u && u < t  // => true

15.970000000000004096は、意味がわからない謎の数字なのです。同じ例は、0.09999999999999986でも見ることができます。

let x : NSDecimalNumber = 0.09999999999999986
_ = x.stringValue  // => "0.09999999999999983616"

0.09999999999999983616はどこから出てきたのでしょうか。ちなみに0.09999999999999986と0.09999999999999983616の間には0.09999999999999985があります。

正しい実装の例

さて、DoubleをNSDecimalNumberに変換する正しいコードは次のようになります。この関数にFloatの15.97を与えると15.97を指すNSDecimalNumberが得られます。0.09999999999999986と0.09999999999999987のような場合に注意は必要ですが、それは仕方ないでしょう。

ちょっと難しいかもしれませんが、がんばって読んでみてください。

func decimalNumberWithDouble(double: Double) -> NSDecimalNumber {
    let number = double as NSNumber
    return NSDecimalNumber(string: number.stringValue)
}

参考にしたもの

直接この問題について理解するというよりは、ぼんやり眺めて浮動小数点の周りの空気がわかった気がした。

2016-03-14

特定のMacでビルドできないXcodeプロジェクト

Xcodeに登録されているファイルの名前とファイルシステム上の名前が大文字小文字で違っている場合、Apple Storeから買ってきたばかりのあなたのMacではビルドできるかもしれませんが、Case Sensitiveなファイルシステムに設定しているMacではビルドできません。

f:id:soutaro:20160314100916p:plain

この画像でUBTypedJSONDictionary.hとなっているソースコードは、ファイルシステム上はUBTypedJsonDictionary.hでした。なんでこうなったかというと、コードレビューで「NSJSONSerializationがあるのだからここはJSONであるべき」と指摘されて、なるほどと思ってXcodeでRenameしたらファイルシステムがついてこなかったからです。

注意しましょう。

注意したくない人は、Xcodeプロジェクトに登録されたソースコードをスキャンして、Case Sensitiveなファイルシステムで問題になりそうな場合に警告するプログラムを作ったので、CIで実行したら良いと思います。

github.com

2016-03-10

CI完了を待ってPRをマージするbotを作るためのライブラリを公開しました

CIを待って自動でPRをマージするbotを作ると便利だった - soutaroブログで、紹介した、CIが完了したときに自動でPRをマージするbotですが、皆さんが簡単に実装できるようnpm packageにしました。

github.com

動くと良いですね。（npm packageはまだ試してない。）

2016-03-08

CIを待って自動でPRをマージするbotを作ると便利だった

GitHubを使っている場合「Pull Requestが作られたら自動でCIを実行し、グリーンになることを確認してからマージする」というのは割と広く採用されている開発のフローだと思います。PRごとにCIすることを確実にすることで、うっかりビルドを壊すようなPRをマージしてしまうことを防ぎ、いつの間にかmasterが壊れることを防ぎます。*1「CIが通っていないPRをマージしない」というのは、GitHubでそういう制約を設けることもできますし、そこまでやらずにチーム内の約束として共有しても良いでしょう。（ユビレジでは後者を採用しています。）

問題は、CIは一瞬では終わらないことです。ユビレジの場合、RailsのWeb appのCIには15分ほどかかりますし、iPad appのCIは30分かかります。CIのためのリソースにも限りがあるので、状況によっては既に15個CIのジョブが溜まっていて、完了までに1時間かかるなんてこともあります。もちろんこれは仕方がないことで、丁寧にコードレビューしてからPRをマージするような場合には問題にはなりません。どうせレビューするのに時間がかかるので、CI待ちの時間は相対的に小さなものとなります。しかし、ちょっとしたtypoの修正とか、コードレビューでokが出てからrebaseしたような場合だと、結構辛い。typoの修正は30秒くらいでレビューが終わったりしてすぐにマージしたくなるものですし、rebaseしただけのようなものも何十分もCIを待つのは苦痛です。CIを待たずにマージすることもできるようにはなっていますが、これはCIが動かないとか本当に急いでデプロイしたい場合の最後の手段なので、CIを待つのがダルい程度の場合にやっちゃうのは避けたい（避けるように訓練しています）。CIが完了するまでの間に他の作業を始めてしまったりすると、今度はマージするのを忘れたりするわけです。これはこれで辛くて、Webサイトのtypoの修正であれば早くデプロイした方が良いですし、下手をすると別のPRがマージされて再度rebaseしなくてはいけなくなったりして、とても辛い。

問題は、CIが完了すればマージして良いPRがあったら、CIが完了するまでそのことを覚えておいて、CI後に確実にマージしなくてはいけないことです。どう考えても、これは人類がやるべき仕事ではなくて、コンピュータにやらせるべき仕事です。つまり「CIが終わったらPRを自動でマージしてくれるbot」が必要です。必要だったので作りました。何ヶ月か動かしていますが、良い感じです。

f:id:soutaro:20160308113820p:plain

CI後に自動でPRをマージするには、ShipItというLabelを付けます
- やっぱりこれはまずいな、と思ったら、Labelを取れば良い
- 不安な場合は、コメントを付ければSlackに通知が行くので、どうしても止めたい人がそれを見たら反応します
GitHubのHookでHubotにCIの完了が通知されたら、PRを探して、ShipItラベルが付いていたらマージします

これが便利に使えるための暗黙の背景としては、

開発チームは誰でもPRをマージできる（基本的には、PRを作った人が覚悟を決めてマージボタンを押す）
マージされるとWeb appはProduction環境に自動でデプロイされる
うっかり間違ったバージョンをデプロイしてしまっても、Herokuの機能で簡単にロールバックできる

などがあると思います。*2

とても便利なので、皆さんも簡単に実装できるようnpm packageにしました。

github.com

*1:とは言っても、複数のPRが同時にopenされる状況では、masterが壊れることを確実に防げるわけではありませんが。

*2:「開発チームは誰でもPRをマージできる」というのは、実は過去に問題になったこともあるのですが、それでも他の色々な条件を考えてポリシーとして受け入れています。

2016-02-25

Swiftでas!と書く場合のガイドライン

as!って言うのは、要するにダウンキャストできない場合にプログラムを終了させるものである。

if let x = expr as? SomeClass {
  f(x)
} else {
  fatalError()
}

と書くのであれば、

f(expr as! SomeClass)

と、同じことなので、as!で書いた方が良い。その方がタイプ数が減るし、コードの見た目も簡潔になって理解しやすくなる。長いコードはそれだけで苦痛だし、なにか間違ったプログラミングをしていることを示すシグナルにもなる。ダウンキャスト失敗の場合に終了するためだけにifを書くことは、全体的なコードの乱雑さを増してしまい、本当の問題の見落としに繋がる。

ただし、as?とかas!とかダウンキャストをしてる時点で、そのプログラムには潜在的な問題があると考えることもできて、本当にダウンキャストが必要なのか3回くらい考えた方が良い。

`as!`とObjective Cのキャストの違い

Objective Cのキャストは常に成功する
as!は失敗してエラーになることがある

この違いをまず頭に入れよう。次のObjective Cプログラムはエラーにならずに実行できる。

NSArray *x = (NSArray *)@"Hello World";

キャストは、コンパイルエラーにならないし実行時エラーにもならない。NSArrayにあってNSStringにないメソッドを呼び出すと実行時エラーになるが、キャストそのものは失敗しない。この性質は、3年に1回くらいは便利なこともあるが、大体は不便である。不正にキャストしたxが、ずっと先の全然ちがうところで実行時エラーを起こしたりするので、間違いを探すのに苦労することになる。

一方、次のSwiftプログラムはコンパイルはできるが実行するとエラーになる。

let x = "Hello World" as! Array<String>

Swiftは、不正なキャストに失敗してエラーを発生させる能力を獲得したのだ*1。これは、Objective Cに比べるとかなり改善されていて、不正なキャストからずっと先の全然違うところで実行時エラーになってデバッグに苦労することがなくなる。

この点で、Objective CのキャストとSwiftのキャストはかなり性質が違うものである。isKindOfClass:でテストせずにキャストするObjective Cのコードはかなり書かないほうが良いが、as!するSwiftのコードはかなりマシであると言える。

さらに、キャストに失敗したときに何が起きるかは決まっている。あなたのプログラムが終了するだけである。iOSに影響が及ぶことはないし（あったとしたらそれはOSの問題だ）、iPhoneが壊れることもないし、鼻から悪魔が出てくることもない。（ただし、アプリケーションやユーザーの性質によっては、それでも強制終了しない方が良い場合はあるとは思う。）

`as!` した方が良い場合

ダウンキャストに失敗した場合にそこから回復する手段がないとき、つまり直ちにプログラム終了するしかない場合はas!してしまう方が良い。「キャストに失敗したらプログラム終了」というのがas!の意味なので、わざわざ冗長にifを書く必要はどこにもない。

`as?`した方が良い場合

ダウンキャストに失敗しても処理が続けられる場合は、as!してはいけない。例えば、View Controllerに書かれているような、ユーザーとのインタラクションを担うようなコードの場合は、ダウンキャストの失敗というなにかプログラム実行の大前提が崩れるような事態にも、適切なエラー回復の手段を提供できる可能性がある。

どのくらい頑張ってエラー回復するかというのは、アプリケーションやユーザーの性質に関する問題なのでなんとも言えない。

コードレビューをしていて`as!`を見つけたら

本当にプログラムを終了する以外に回復の方法がないのか、議論して良いし、議論するべきである。適切な回復の方法があるのであれば、そちらに直す。また、as!もas?もしないことについても検討する。標準ライブラリとかObjective Cとの相互運用を除けば、「enumにしてswitchする」「protocolを追加して分岐しなくて良いようにする」などの方法がある。

Lintとどうつきあうか

個人的には、as!に警告するルールはオフにするのがお勧めだけど（僕はLint大嫌いなので、多分これは少し極端な見解だろうとは思う）。まー現実的には、堂々と

// swiftlint:disable:next force_cast

と書くのが良いだろう。これを見たレビュアーは強制終了するほかにエラー回復の方法がないのかあなたに説明を求めるだろうし、あなたは説明できなくてはいけない。

*1:ちなみに、不正なキャストに失敗する能力は、JavaやC++などのCやObjective Cよりも新しい言語は、だいたい1990年代に獲得しているものである。2016年にもなって失敗する能力が欠けているObjective Cが異端であるとも言える。

2016-02-22

それでenumとclassのどっちにすれば良いの？

SwiftのenumがObjective Cで欲しいときはどうするか - soutaroブログ

この記事には

enumが便利なのは

ある状態では有効だけど、別の状態では有効ではない値を定義するとき

です。

と書きましたが、「それはサブクラスっていうやつではないか」という声があります（どこに？）。その通りで、enumとクラスはよく似ている側面があって、enumでできることはクラスでも（再コンパイルの量とか、網羅性の検査とか、isKindOf:とか、キャストとかの問題を見なかったことにすれば）できるという話でした。

ここで疑問になるのは、

なぜSwiftにはenumとclassという似たような機能が二つ用意されているのか（TMTOWTDI？）
何を考えてenumとclassを使い分ければ良いのか

でしょう。

enumとclassの違い

Swift的には「classは状態を持てるがenumは持てない」という違いがあります。これはSwiftがプログラミング言語の設計として導入した恣意的な制限で*1、もう少し抽象的にはenum (ADT) とclassには次のような違いがあります。

enumは個々のcaseを追加するのは大変だけど、値の操作を追加するのは楽
classは個々のサブクラスを追加するのは楽だけど、操作を追加するのは面倒

enumにcaseを追加すると、全体的にあなたのコードは全体的にコンパイルし直しで、多分switchがエラーになりまくります。黙って実行時エラーにされるよりはマシですが、一つ一つ確認して、丁寧に手作業で修正してまわらないといけません。めんどくさい。一方で、クラスにサブクラスを追加した場合はなにが起きるかというと、全体のコンパイルは必要ないし、既にスーパークラスを使っている部分もソースコードを修正する必要がありません。楽。

逆に、enumに操作を追加するのは簡単で、switchを書けばそれで終わりです。プログラミングしてて、「あ、ここはそれぞれのcaseで別々の操作が必要だな！」とか多分考えもせずに、無意識にswitchを書くことになるでしょう。classに操作を追加するのは、スーパークラスにメソッドを追加して、サブクラスで全部実装してまわると言うことです。まずメソッド名を考えないといけませんし、中身が一行だけだったりするとそもそもfuncとか書くのも面倒ですし、サブクラスを全部探すのも面倒ですし、ファイルを開いてまわる時点で面倒です。ああなんて面倒。

継承とオブジェクトの仕組みはある種のプログラミングを楽にしましたが、一方でad-hocに操作を追加できないことが問題になることもあります。isKindOf:やキャストのような仕組みでこの問題は回避できますが、一方で安全性が失われます。実行時の型検査によって危険性は押さえられていますが、もっと型システムを活用したい場面はたくさんあります。このようなad-hocに操作を追加したいようなデータ型には、enumのようなアブローチが向いています。

さて、enumとclassのどちらを使えば良いかはかなり明らかになりました。

caseは増えなさそうだけど、操作が増えそうな場合はenumを使う
操作は現時点でだいたいわかっているけど、caseが増えそうな場合はclassを使う

簡単ですね。

ちなみに個々の型についてenumとclassのどちらを選ぶかですが、僕の場合は、ADTの方が先に頭にあるのでまずはenumで書けないか考えることになります。それで

状態を変更する方が楽に実装できそうな予感がある
継承して実装を使い回したい
関連する操作が（直感的に）すでにわかっている

など、enumで書くのは微妙な感じがする場合には、classにします。

Expression Problem

enumとclassの違いは、関数型プログラミング言語とオブジェクト指向プログラミング言語の違いとして考えることができます。この問題はExpression Problemという名前で昔々に議論されていたりします。

Expression problem - Wikipedia

WikipediaからリンクされているWadlerのメール（論文*2）には、次のような文章があります。

In a functional language, the rows are fixed (cases in a datatype declaration) but it is easy to add new columns (functions). In an object-oriented language, the columns are fixed (methods in a class declaration) but it is easy to add new rows (subclasses).

http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt

ここで行 (row) と列 (column) は、それぞれデータの種類と操作を指しています。和訳。

関数型ブログラミング言語では、行は固定されている（datatype宣言のcase）が列を足すのは簡単（関数）。オブジェクト指向プログラミング言語では、列は固定されているが（クラス宣言に含まれるメソッド）行を足すのは簡単（サブクラス）。

さて、「それでは両方とも足せるようにするのはどうしたら良いでしょうか？」というのが、Expression Problemです。回答はいくつかあって、

OCamlではPolymorphic Variantという「すごいenum」を用意して解決した
Scalaもなんかうまいこと解決した（上のWadlerの論文は「俺の考えたGJならExpression Problemが良い感じに解ける」というものなので、きっと関連があるんだろうと思っていますが、Scalaはよく知らないのでわかりません）
Haskellもなんかできるらしい（よく知りません）

とかです。

ちなみに「既存のクラス階層にメソッドを追加しようとするとちょう大変」という側面を見れば、SwiftのExtensionやObjective-CのCategory、C#のExtension Methodsといった機能によって、ある程度は解決される問題でもあります*3。GoFで言えばVisitorパターンがこの問題に取り組むものですね（キャストが必要なので型安全ではない）。

*1:というと、少しニュアンスが違うかもしれなくて、enumがimmutableなのは常識的な設計なんだけど、でも別にmutableであっていけないわけでもない。

*2:URLにpaperって入っている。

*3:でも再帰的なものを考えるとあまり上手くいかない。

2016-02-19

SwiftのenumがObjective Cで欲しいときはどうするか

Swiftではenumという種類のデータ型を定義できます。Cのenumと違って、引数を持てるようになっています。これが便利なのは

ある状態では有効だけど、別の状態では有効ではない値を定義するとき

です（すごい雑な説明なので、他の使い方も調べておきましょう）。

Swiftのenumとは

例えばあなたが最強のレジアプリを開発しているとしましょう。販売する商品の価格には次の二通りがあります。

単価と税率が決まっているもの（単価¥100、税8%）
全体の金額からの割合であるようなもの（10%割引）

enumを使わないで普通のクラスにしようとすると、こんな感じになるはずです。

class MenuItem {
  let isPercentage: Bool
  let unitPrice: NSDecimalNumber!
  let vatPercentage: NSDecimalNumber!
  let percentage: Int!
}

isPercentageが偽のときには、unitPriceとvatPercentageが設定されて、percentageがnilになります。isPercentageが真のときはその逆。optionalがたくさんあって嫌な感じがしますし、いつか普通に間違えそうです。うっかりisPercentageな商品のunitPriceにアクセスしてエラーになるかもしれませんし、それを見た新人がisPercentageなのにunitPriceに0を設定するみたいな間違いを犯すかもしれません。少しでも状況を改善するためにはvalidationのコードを書くこともできますが、退屈なのでできるだけやりたくないですね。

こういうことを防ぐにはenumを使います。

enum MenuItemPrice {
  case Unit(price: NSDecimalNumber, vatPercentage: NSDecimalNumber)
  case Percentage(percentage: Int)
}

class MenuItem {
  let price: MenuItemPrice
}

optionalがなくなってやばそうな感じはなくなり、割引の項目の価格にはpriceがないので間違えてアクセスしようとするとコンパイラが教えてくれます。安心。priceの中身にアクセスしようとすると、必ずswitchが必要になって少し面倒ですが、諦めましょう。

switch price {
  case Unit(let p):
    ...
  case Percentage(let p):
    ...
}

ちなみにswitchを使うと、caseが網羅されているかもコンパイラがチェックしてくれるので、後で価格の種類が増えたときにも安心です。

Objective Cでどうするか

残った問題は一つだけで、2010年から開発されているあなたの最強のレジアプリはObjective Cで書かれているので、こういう良い感じのenumをSwiftで定義してもそれをアプリケーションから使うことは出来ないということです。関連するコードだけでもSwiftで書き直せれば良いのですが、いろいろな事情でそうもいかないことは多いでしょう。

仕方がないのでこうします。

@interface MenuItemPrice : NSObject
@end

@interface UnitPrice : MenuItemPrice

@property (nonatomic) NSDecimalNumber *price;
@property (nonatomic) NSDecimalNumber *vatPercentage;

@end

@interface PercentagePrice : MenuItemPrice

@property (nonatomic) NSInteger percentage;

@end

@interface MenuItem

@property (nonatomic) MenuItemPrice *price;

@end

これで「単価が決まっている価格なのにうっかりpercentageにアクセスしてしまう」ことは防げるようになりました。

こうやって定義した値を使う方法はいくつかあります。

MenuItemPriceにメソッドを追加してサブクラスでオーバーライドする
isKindOfClassして場合分けする

必要なメソッドがわかっている場合は、1.の方法が良いでしょう。例えば「価格を文字列の表現に変換する」みたいな操作は、それでいいと思います。私の場合は、さっさと諦めて、isKindOfClassで場合分けすることが多いですね。

if ([menuItem.price isKindOfClass:[UnitPrice class]]) {
  UnitPrice *price = (UnitPrice *)menuItem.price;
  ...
}

isKindOfClassのような操作はオブジェクト指向プログラミングでは避けるべきとされていますが、ここでは別にOOしたいわけではないので良いことにします。キャストが少し面倒なので、ヘルパーを足すことがあります。

@interface MenuItemPrice

- (void)asUnitPrice:(void (^)(UnitPrice *))block;
- (void)asPercentagedPrice:(void (^)(PercentagedPrice *))block;
- (void)switchWithUnitPriceCase:(void (^)(UnitPrice *))unitCase percentagedPriceCase:(void (^)(PercentagedPrice *))percentagedCase;

@end

もしも価格の種類が増えた場合にコンパイルエラーになるようにするため、switchWithUnitPriceCase:percentagedPriceCase:も入れてみました。

まとめ

Swiftのenumって要するに代数的データ型 (Algebraic data type / ADT) なので、Objective Cに欲しい場合は、どうしてもOOPLでADTしたい場合のパターンで逃げることができます。

Floatのリテラルとは

15.970000000000004096

正しい実装の例

参考にしたもの

as!とObjective Cのキャストの違い

as! した方が良い場合

as?した方が良い場合

コードレビューをしていてas!を見つけたら

Lintとどうつきあうか

enumとclassの違い

Expression Problem

Swiftのenumとは

Objective Cでどうするか

まとめ

`as!`とObjective Cのキャストの違い

`as!` した方が良い場合

`as?`した方が良い場合

コードレビューをしていて`as!`を見つけたら