C++0xのCommittee Draftへのコメントへのコメント

コメント一覧を一通り読みましたが, 来週の会議には後半から3時間くらいしか出れないので今の内にコメントを書いておきます。
コンパイラ実装上の観点を中心に。

01. decltypeにスコープ演算子(::)を使用できない

これは賛成です。
ところで, simple-type-specifierからdecltypeを削除しちゃったら, 型として使えませんからこの削除はいけません。
また,

nested-name-specifier:
    ...
    decltype(expression) ::

の最後の::が抜けています。

# この場合, 構文規則に衝突は起きていないだろうか...?

04. noreturn属性の挙動

attributeはコンパイラが解析できない情報を教えてあげる為にあるものですから, attributeが正しいかコンパイラが解析するというのは本末転倒です。
ここでいう「返る」は「返るパスがある」とは意味が違いますから, コンパイラで解析することは不可能です。

# ところで,個人的にはこういうattributeは処理系任せにしちゃった方が良いんじゃないかと思うんですがどうなんでしょうか。どっちみち, 処理系がいろいろ新しいattribute追加しだすと思うので。attribute用の構文を用意したというだけではいけないのでしょうか。

14. コンセプトによってイテレータの機能が制限される

std::RangeコンセプトのイテレータがInputIteratorな理由の一つに,最適化があると思います。
std::Rangeには範囲ベースのforループを記述する為の役割があるわけですが,この拡張のおかげでコンパイラによる自動並列化等のループ最適化が楽になります,しかしこれがランダムアクセスイテレータだとせっかくの範囲ベースが無駄になります。

なので, 私はstd::Range::iteratorがInputIteratorである事を支持します。

26. std::cin などをbinary reopenできる方法がほしい

これはstd::ios::binaryを間違えて理解しています。
標準入力からバイナリを入力するという場合にstd::ios::binaryを指定する意味はないです。
非POSIX準拠システムではファイルシステム中のテキストファイルとバイナリファイルを別々に扱うものがあり, その為にstd::ios::binaryは用意されています。テキスト"データ"とバイナリ"データ"を区別する為のものではないですから, 標準入力からバイナリデータを入力する場合は普通に(streambufとかで)読めば良いです。