読者です 読者をやめる 読者になる 読者になる

meryngii.neta

今日も新たな"ネタ"を求めて。

Committee Draft 1への日本からのコメントのその後

C++ C++0x

C++0xのCommittee Draft 1への日本からのコメントのその後について適当に書いてみました。
C++ CD1 Comment Status
まあ原文を読んでもらえば済む話なのですが、半年経った今改めて振り返るためにまとめました。
結構数があるので今回はtypoの修正等を省略させてもらい、独断と偏見によって技術系の提案のみに絞ります。

  • JP-5 raw-stringの結合規則
  • JP-8 decltype(T)にスコープ解決演算子::が使えない
  • JP-9 ラムダ式にムーブキャプチャ &&がほしい
    • ラムダ式に変数を取り込むキャプチャの方法としてコピーではなくムーブを使いたいという要望。
    • 名前の付いた変数からムーブすることはできないとしてrejected。
    • まともな解決策はあるのだろうか。
  • JP-10 ラムダ式の匿名関数オブジェクトの型にresult_typeがほしい
    • std::result_ofは指定された型のresult_typeを返すので、ラムダ式の型にもつけるべきだという主張。
    • 今のstd::result_ofはdecltypeで作られてるので関係ないとしてrejected。
  • JP-12 constexprの再帰を認めるべき
  • JP-14 inline namespaceの名前の重複について
    • inline namespaceとすると外側の名前空間でもアクセスできるようだが、外側の名前空間と名前が重複したらどうなるのかということについて。
    • openのまま。
    • using directive(using namespace 〜;)が自動的に挿入されたようになる(7.3.1.8)と書いてあるので、それで理由づけられるような気がする。
    • 812. Duplicate names in inline namespaces
  • JP-21 char16_t/char_32_tの対応が不十分
    • iostreamにあるwostreamにはu16ostreamをなど、文字列を扱うライブラリにUnicode版のtypedefを追加せよという要望。
    • 型が増加すると大変だから、面倒くさがらずに変換してくれということでrejected。
    • 現実的な対応ということなのだろうか。
  • JP-23 フリースタンディング環境で使用できるヘッダの追加
  • JP-27 標準ライブラリ関数にnoreturn属性を追加
    • exitなどはユーザ側に処理が返ってこないことが明確なのでnoreturn属性を付けてほしいという提案。
    • 見過ごされているような雰囲気。
    • extern "C"な関数に属性を付けられるのだろうか。
  • JP-28 例外クラスのUnicode対応
    • std::exceptionなどで例外メッセージにwchar_tやchar16/32_tを使いたいという要望。
    • 呼ぶ側が国際化せよということでrejected。
    • JP-21と同じ見方でよいのだろうか。
  • JP-30,31 nested_exceptionは木構造をサポートすべき、または削除すべき
    • 例外が連鎖するような場合のためにnested_exceptionというものが追加されたが、木構造をサポートしないと使い物にならないという話。
    • openのまま。
    • 関数の広がりは分岐しながら進んでいくので、自然に木構造になるということだろうか。
    • id:wraith13氏ががんばってくれたらしい。C++0x の nested_exception について 其の参(考察) - TrickDiary
  • JP-32 exception.what()のメッセージが役に立たない
    • 例外のメッセージを見ても何の例外かも分からないようなものばかりなので、役に立つものにするよう明記してくれという要望。
    • 実装依存、ということでrejected。
  • JP-38 bindの戻り値の型がムーブできない
    • bindの戻り値の関数オブジェクトは、ムーブが実装されておらずコピーされる可能性がある。
    • open状態だが解決案は提示されている。
    • USやDEからも同様のコメントあり。
  • JP-62 is_xxx関数がイテレータを返すのに違和感がある
    • 一般的にis_xxxはbool型を返すというルールがあるのに、is_sorted_until、is_heapというイテレータを返す関数がある。そこでこれらの名前はxxx_boundに変えるべきという提案。
    • 名前について合意が得られていないとしてrejected。
    • この名前になった元々の合意とやらはあるのだろうか…。
  • JP-63 discrete_distributionにinitializer_list版のコンストラクタがほしい
    • discrete_distributionという乱数のクラスでイテレータだけでなく初期化リストによっても初期化できるようにしてほしいという要望。
    • これはaccepted。最新のhttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2836.pdf:N2836を参照とのこと。
    • 辞書によると離散型分布というものらしい。よく分からない。
  • JP-64 valarrayのinitializer_list版のメンバ
    • valarray& operator+= (initializer_list); が定義されていないことについて。
    • 見過ごされている予感。
    • ところでvalarrayって何に使うのだろう。
  • JP-74 basic_regexのinitializer_list版のメンバ
    • JP-64との関連で、basic_regx & operator= (initializer_list); が定義されていないことについて。
    • tentatively ready(とりあえず準備完了)状態。
  • JP-65,66 unspecified-bool-type からexplicit operator bool() constへ変更すべき
    • せっかくExplicit Conversion Operatorsがあるのだから使おうぜという話。
    • 見過ごされている予感。
  • JP-73 のUnicode対応
    • fstreamのファイル名はchar16/32_tどころかwchar_tも使えないということについて。
    • まだ議論されていないようだが、JP-21,28と同じ方針でrejectされそうな予感。
  • JP-75 Atomic Operation Libraryのenum/structの定義方法がCの古い文法になっている
    • typedef struct { 〜 } 〜;などの古い記法が使われているので直すべきという提案。
    • C言語との互換性を保つためにわざとこうしてあるとしてrejected。
  • JP-76 "Throws: Nothing"の記述ポリシーが一貫していない
    • Throws: Nothingが書かれていないものがあることについて。
    • 編集的な問題ではないとしてopenのまま。

コンセプトに関する提案(JP-20,26,29,33,39〜43,45,46,48〜50,52,53,55,60,67〜69,72,77,79,81)は、コンセプトが追放された模様なので扱いませんでした。復活したら書くかもしれません。