読んだもの１ P0145R1: Refining Expression Evaluation Order for Idiomatic C++ 稲葉
WHAT IT IS std::cout << f() << g() << h(); C++14 : f(), g(), h() の評価順序は未規定 提案 : f(), g(), h() の順で評価 std::map<key_t, size_t> m; m[key] = m.size(); C++14 : m[key] が 0 になるか 1 になるかは未規定 提案 : 0 になる void foo(unique_ptr<T> x, unique_ptr<T> y); foo(new T, new T); C++14 : メモリリークするかも 提案 : しない などなど、ある程度評価順序を規格で決める
WHAT IT IS *NOT* x = x++; f( a(), b(), c() ); これは変わらず未定義 ただし、(改造版Visual C++で実験してみた結果)“we feel confident recommending the left-to-right evaluation rules” と書いてあるので今後変わるかも
MOTIVATION foo().bar().buz() のようなメソッドチェーン << をストリームへの出力演算子として使う (cf. std::future<>::then) << をストリームへの出力演算子として使う スマートポインタ などなど、Cに遡る “評価順序は不定” が最初に定義 された頃から比べると、様々なイディオムが発達して きており、それらのイディオムを自然に活用できるよう に言語サポートがあるべきだ」
この提案に関するMLのスレッド 「E << F」 と 「E <<= F」 で順序違うのは… 「E = F」 が右から左で Java や C# と違うのは… 「演算子の結合方向を考えても代入演算だけが右から 左なのは自然」 「C# チームに何故左から右と定義したのか聞いてみた ら（C++のように）左辺で頑張りまくることは、そもそもC# では少ないので…という反応だった」 Bjarne 「今新しく言語を設計するなら代入は左手の値 が右手に入るようにするんだけどなあ （脱線）」
この提案に関するMLのスレッド 「*ptr_expr = big_struct_expr;」 で先に左辺でア ドレスを計算してそこに右辺の結果を直に書き込むと いう最適化ができなくなる 「逆に右to左だからこそできる最適化も色々あると GCCの人は言っていた。it depends だ」
読んだもの２ P0144R1: Structured bindings See Also: P0217R0: Proposed wording for structured bindings
WHAT IT IS
PROPOSED IMPL 右辺が配列型なら展開 右辺の型に対して .get<#>() メンバ関数か get<#>() ADL関数が適用できるなら、それを使っ て展開 構造体/クラスなら public メンバの先頭から順に 展開
DESIGN CHOICES auto のみ (明示的な型宣言やconcept宣言は扱わない) auto& や const auto は サポート “Should there be a way to explicitly ignore variables?” not yet. std::tie における std::ignore 的な物を用意できたらい いが、変数宣言部なので簡単ではない “Should there be support for recursive destructuring?” not yet. 「複雑なことは pattern matching (C++ 2X?) を入れるときにそ のsyntaxに合わせるように考えたい」
この提案に関するMLのスレッド (合計で300レス以上燃えている) 右辺のtupleよりも変数リストが短い場合はエラーにすべ きでは？ そうする方向に検討が進んでいる模様 提案中のstd::variant にも get<#>があるので“分解”で きてしまう問題 問題が認識され始めたところ、議論中 auto じゃない型を明示させろ派が大変活発 Bjarne が蹴り続けている auto {x, y} = std::ensure<int, string>(f()); のようなヘルパー が書けるからいいだろと言っている人もいる。