pre-Madrid mailingの簡易レビュー

Pre-Madrid mailingが公開された。

最新のドラフトは、N3242となった。N3225からの大きな変更はない。typoの修正などにとどまっている。

N3233: Decltype and Call Expressions

decltypeの型は完全型でなければならないが、これは不必要にきつい制限であるとのこと。例えば、以下のコードはエラーになる。

struct S ;
S void f() ;

using type = decltype( f() ) ; // ill-formed.

このため、decltypeの式が関数呼び出しであり、戻り値の型が不完全型である場合を許可するという提案。

N3234: Remove explicit from class-head

クラスのメンバーの明示的なチェックを強制するexplicitを廃止する提案。現時点では、まだ時期尚早である。

N2335: Generalized pointer casts

ライブラリでは、static_castを用いた、異なるポインター型の間での型変換という要求があるが、これは、ポインターのようにふるまうクラスでは、難しい物がある。そこで、pointer_traitsを新たに定義し、static_castの代わりに用いることにする提案。

N3241: Moved-from state

ムーブされた後のオブジェクトの状態を規定する提案。標準ライブラリに渡すオブジェクトは、ムーブされた後も、指定された要求を正しく行わなければならない。例えば、代入可能なことを要求している型の場合、ムーブした後のオブジェクトに代入した場合、ちゃんと動作するように実装しなければならない。

N3248: noexcept Prevents Library Validation

noexcept指定された関数から例外がthrowされた場合の挙動を、terminateから未定義動作に変更する提案。

理由は、デバッグのためである。デバッグ用に、STLでクラスの内部状態をチェックして、不正な場合に、エラーを出すという手法は、一般的である。たとえば、イテレーターが参照された場合、本当に妥当な要素を参照しているのかどうかをチェックするような機能である。

noexceptを、規格制定のかなり遅い段階で取り入れたことにより、また、noexceptが実際に有用であることにより、ライブラリWGは、既存の関数を、noexcept指定すべきかどうか、洗いざらいに検証した。しかし、noexcept指定された関数からは、例外を投げられないので、デバッグ版ライブラリの実装、また安全なライブラリの実装は、できなくなってしまう。

現実の実装では、コンパイルにはモードを付けるべきだろう。ひとつはテストモードであり、noexcept指定された関数からの例外のthrowを、通常通りサポートする。もうひとつは、プロダクションモードであり、こちらは、terminate()を呼び出す。

もちろん、モードというものは、規格では言及されていないし、また、現時点では行うべきではない。そのため、noexcept指定された関数から例外が投げられた場合の挙動は、このような実装を可能にするため、未定義動作にすべきである。

N3250: US-18: Removing User-Defined Literals

ユーザー定義リテラルを取り除く提案。ユーザー定義リテラルには実装経験がない。実装がないために使用経験もない。C99の16進数浮動小数点数リテラルの文法と衝突する。ユーザー定義リテラルを規格から取り除くためのコストは低い。何故ならば、ユーザー定義リテラルを使っている、他のコード、文面、標準ライブラリはないからである。

これは当然だろう。ユーザー定義リテラルは取り除くべきだ。

N3258: US-65: Removing Inheriting Constructors

継承コンストラクターを取り除く提案。継承コンストラクターには実装経験がない。実装がないために使用経験もない。継承コンストラクターはVariadic Templatesでエミュレート可能である。継承コンストラクターを規格から取り除くためのコストは低い。何故ならば、継承コンストラクターを使っている、他のコード、文面、標準ライブラリはないからである。

継承コンストラクターの廃止は惜しいが、確かに、コンストラクターのデリゲートに比べれば、あまり魅力的ではない。廃止されても仕方がないだろう。

N3253: A Proposal to Tweak Certain C++ Contextual Conversions

ifやwhileなどでは、式がある型、たとえばbool型に変換可能であることを要求している。現行の文面は、変換先の型以外には、全く同じことを、それぞれ微妙に異なる文面で定義している。このような定義はまとめるべきである。

この提案は、ある型へ変換可能であるという意味の、contextually convertedという用語を定義し、他の文面では、単にbe contextually convertedという言葉を用いるように変更する。

N3254: Proposed resolution for US104: Allocator-aware regular expressions (rev 2)

正規表現ライブラリをアロケーターに対応させる提案。

N3255: C++ Decay Copy

std::forwardの戻り値の型を、std::decayを適用した型にした、std::decay_copyを追加する提案。単純だが、標準ライブラリにあるべきヘルパー関数である。ちなみに、実装は以下の通り

template <class T>
typename decay<T>::type decay_copy(T&& v)
{ return std::forward<T>(v) ; }

N3257: Range-based for statements and ADL

この問題については、本の虫: range-based forに対する意見求むで解説した。私は案4を推している。