Re: Evolution
Swift開発メンバーの冬休みが合わずにミーティングができなかったのか、しばらく動きが止まっていたswift−evolutionのプロセスがようやく再開された。
SE-0015: Tupleの比較演算子。適当なn-tupleまで比較演算子を定義しちゃいましょう案。実装方法的にかなり微妙だったんで、あまり美しくない提案だと思ったのだが、採用されたら即実装済みってことになった。そりゃ腕力でどかんと実装するのは難しくはないわな。nの値がいくつになったのかは未確認。ちなみにSwiftにimportされた標準Cライブラリーのデータ型には256-tupleなんて珍しくないのだが、さすがに256-tupleの比較はできないと思う。
SE-0009: self.必須案、正式にrejectされた。私的には喜ばしい。実はあれこれ調べて長文の反対意見を送ろうかと思ったのだが、調べれば調べるほど私でも書けるような意見は誰かが既に書いているのに気付いた次第。それでも数の上で微妙なら何か書こうかと思っていたが、圧倒的に反対票優勢だったので、それもやめ。私のMLデビューはもう少し先になりそうである。つけたい人がつけるのには反対しないからさ、必須にするのはやめとくれ。
SE-0008: 我ながら全く翻訳になってないじゃんと思っていた、「LazyなflatMapをOptionalなSequenceTypeに追加」案。Swift2.2に採用。
SE-0014: AnySequence.initへの制約追加。Swift2.2に採用決定。
間も無くReview終了:
SE-0011: protocol中でassociated typeを宣言するのに使っていたtypealiasは本家のtypealiasとは全然意味合いが違うんだから別のキーワードに変えましょうって提案。最初にMLに登場した時は、変えさえすればなんでも良い的な書き方だったが、さすがにそれではproposalにならなかったようで、associatedってキーワードが原案になった。MLはあまり盛り上がっていないが、多分通るだろう。
間も無くReview開始:
SE-0010: StaticStringもUnicodeScalarViewを返せるようにしようという話。ま、あれば便利だわな。
(January 6...7, 2016)…期間が短すぎるんでないの?Swiftチーム的には採用が既定事項なんだと思う。
SE-0013: final以外のsuperのメソッドの部分適用(引数を与えずにクロージャーとして取り出すこと…ま、カリー化ありだともうちょっと広い意味になるが)を廃止しましょうって案。言語としての整合性的にはちょっと微妙なんだが、現在の仕様も微妙っちゃ微妙だから、ダメに決めますと言われたら、はいそうですか、と言っちゃいそう。んが、実装上の詳細が根本にあるっぽいので、実装方法変えたらやっぱり復活させたくなったと言われそうな気もする。
(January 7...11, 2016)
SE-0018: memberwiseなんて新しいキーワードを導入して、イニシャライザをもうちょっと使いやすくしましょうって話。これも美しくはないのだが、Swiftはイニシャライザに関する規則が細かいので、美しい方法で抜本的に改善できる案を作れと言われると困ってしまう。
(January 6...10, 2016)開始日はSE-0010と同じなんだが、既にレビュー中扱いになっていた。
いちいち追っかけるのは大変だな。多分今後は書かないぞ…。
また、まもなくSwift2.2用のブランチを切って、その後のmasterはSwift3.0に向ける宣言がなされた。私的には自分のプロジェクトの1つがSwift2.1以降コンパイルできなくなっていたので、なんとか2.2ではそれを解消させたかったのだが、いまだに修正案どころか、バグ報告さえ書けていない始末。Swiftをまるごとビルドしたら(そこそこハイスペックのマシンでも)5時間くらいかかった、なんて話もあるので、そうおいそれとコード修正には貢献できそうにない。取り急ぎバグ報告だけでもまとめなければ。
SE-0015: Tupleの比較演算子。適当なn-tupleまで比較演算子を定義しちゃいましょう案。実装方法的にかなり微妙だったんで、あまり美しくない提案だと思ったのだが、採用されたら即実装済みってことになった。そりゃ腕力でどかんと実装するのは難しくはないわな。nの値がいくつになったのかは未確認。ちなみにSwiftにimportされた標準Cライブラリーのデータ型には256-tupleなんて珍しくないのだが、さすがに256-tupleの比較はできないと思う。
SE-0009: self.必須案、正式にrejectされた。私的には喜ばしい。実はあれこれ調べて長文の反対意見を送ろうかと思ったのだが、調べれば調べるほど私でも書けるような意見は誰かが既に書いているのに気付いた次第。それでも数の上で微妙なら何か書こうかと思っていたが、圧倒的に反対票優勢だったので、それもやめ。私のMLデビューはもう少し先になりそうである。つけたい人がつけるのには反対しないからさ、必須にするのはやめとくれ。
SE-0008: 我ながら全く翻訳になってないじゃんと思っていた、「LazyなflatMapをOptionalなSequenceTypeに追加」案。Swift2.2に採用。
SE-0014: AnySequence.initへの制約追加。Swift2.2に採用決定。
間も無くReview終了:
SE-0011: protocol中でassociated typeを宣言するのに使っていたtypealiasは本家のtypealiasとは全然意味合いが違うんだから別のキーワードに変えましょうって提案。最初にMLに登場した時は、変えさえすればなんでも良い的な書き方だったが、さすがにそれではproposalにならなかったようで、associatedってキーワードが原案になった。MLはあまり盛り上がっていないが、多分通るだろう。
間も無くReview開始:
SE-0010: StaticStringもUnicodeScalarViewを返せるようにしようという話。ま、あれば便利だわな。
(January 6...7, 2016)…期間が短すぎるんでないの?Swiftチーム的には採用が既定事項なんだと思う。
SE-0013: final以外のsuperのメソッドの部分適用(引数を与えずにクロージャーとして取り出すこと…ま、カリー化ありだともうちょっと広い意味になるが)を廃止しましょうって案。言語としての整合性的にはちょっと微妙なんだが、現在の仕様も微妙っちゃ微妙だから、ダメに決めますと言われたら、はいそうですか、と言っちゃいそう。んが、実装上の詳細が根本にあるっぽいので、実装方法変えたらやっぱり復活させたくなったと言われそうな気もする。
(January 7...11, 2016)
SE-0018: memberwiseなんて新しいキーワードを導入して、イニシャライザをもうちょっと使いやすくしましょうって話。これも美しくはないのだが、Swiftはイニシャライザに関する規則が細かいので、美しい方法で抜本的に改善できる案を作れと言われると困ってしまう。
(January 6...10, 2016)開始日はSE-0010と同じなんだが、既にレビュー中扱いになっていた。
いちいち追っかけるのは大変だな。多分今後は書かないぞ…。
また、まもなくSwift2.2用のブランチを切って、その後のmasterはSwift3.0に向ける宣言がなされた。私的には自分のプロジェクトの1つがSwift2.1以降コンパイルできなくなっていたので、なんとか2.2ではそれを解消させたかったのだが、いまだに修正案どころか、バグ報告さえ書けていない始末。Swiftをまるごとビルドしたら(そこそこハイスペックのマシンでも)5時間くらいかかった、なんて話もあるので、そうおいそれとコード修正には貢献できそうにない。取り急ぎバグ報告だけでもまとめなければ。