ULTRA-PERFECT FORWARDING

普通のC++使い、銀天すばる @SubaruG

でも，特殊メンバ関数はこれだと無理（非テンプレートが優先されるので）だから， copy/move は基底に移譲して実装選択，と．

Akso de la Malbono @Cryolite

@SubaruG But it is possible to use template constructors in order to implement ULTRA-PERFECT FORWARDING, isn't it?

普通のC++使い、銀天すばる @SubaruG

@Cryolite ULTRA-PERFECT FORWARDING についてｋｗｓｋ

Akso de la Malbono @Cryolite

@SubaruG Sorry, it's my coined term and means forwarding of [no-throw] constructibility/assignability/convertibility of the underlying type.

普通のC++使い、銀天すばる @SubaruG

@Cryolite なるほど． 僕としては，処理系がテンプレートではない特殊メンバ関数が自動定義する以上，いろいろと考えて可能な限り Perfect にするより，第一引数を forwarding 用の tag にすることで対応する方が現実的と判断しました．

Akso de la Malbono @Cryolite

@SubaruG Yeah, I think it is much more reasonable, too. But I advocate the ideal implementation is also possible with quite heavily TMPs.

普通のC++使い、銀天すばる @SubaruG

@Cryolite そうですね． この辺りは僕も興味があるので，また考えなおしてみます．

普通のC++使い、銀天すばる @SubaruG

っていうか，この辺りの転送問題って，普通にテストファースト手法が使えるね． テストファーストの練習として，一度は諦めたテンプレート型変換コンストラクタをやってみるのも良いかもです．

普通のC++使い、銀天すばる @SubaruG

ToDo リストに「可能な限り完全なテンプレート型変換コンストラクタを定義するというお題で，テストファースト手法を試してみる」を追加しました！

普通のC++使い、銀天すばる @SubaruG

C++11 ネタでソフトウェアエンジニアリングの研修が出来るとか，僕は幸せものですね（白目

普通のC++使い、銀天すばる @SubaruG

それはそれとして， Etude では基本方針として「 ctor の第一引数でテンプレートを推論させるのは止めよう（ただし optional<U> のような部分的に推論するケースは除外）」という方針を取るようにしたいです． 複雑なのは使いにくいですし．

Akso de la Malbono @Cryolite

@SubaruG Complexity MUST be encapsulated in implementation detail, and users MUST NOT be exposed to the complexity.

普通のC++使い、銀天すばる @SubaruG

@Cryolite はい． でも重度のメタプログラミングで切り分けた場合，往々にしてエラーメッセージは意味不明なものになります．

Akso de la Malbono @Cryolite

@SubaruG ULTRA-PERFECT FORWARDING implies that declarations unnecessary to users MUST NOT be visible to users.

普通のC++使い、銀天すばる @SubaruG

@Cryolite しかし，コンパイラのエラーメッセージをユーザに見せることになるのは変わりません．

Akso de la Malbono @Cryolite

@SubaruG It is the reason why error messages from TMPs make little sense that unnecessary declarations are visible to users.

Akso de la Malbono @Cryolite

@SubaruG ULTRA-PERFECT FORWARDING means that it should forward what should be *and it should not forward what should not be*.

普通のC++使い、銀天すばる @SubaruG

@Cryolite うーん． 単純なケースなら可能だと思いますが，例えば optional<T> のような「 T からも変換できる」「none_t からも変換できる」「 optional<U> からも変換できる」「 in_place_factory からも変換できる」ケースだと

普通のC++使い、銀天すばる @SubaruG

@Cryolite 境界部分で曖昧性が生じた場合に，ユーザに対して適切なエラーメッセージを吐かせることって，現実的に可能なのでしょうか？

Akso de la Malbono @Cryolite

@SubaruG At least, compile-time stack trace by TMP does (should) not become deeper than immediate contexts of the outer type.

Akso de la Malbono @Cryolite

@SubaruG Ah, yes, you are quite right.

Akso de la Malbono @Cryolite

@SubaruG After a little thought on this, I think compilers can produce simple error messages in such a case.

Akso de la Malbono @Cryolite

@SubaruG Because this ambiguity https://t.co/AUjEE714 is converted to a compile-time constant in the immediate context of the outer type.

普通のC++使い、銀天すばる @SubaruG

…ん． ってか，この手の話題って普通に英語で話すべきなんじゃ？ 多くの人に議論を読んでもらうためには．

普通のC++使い、銀天すばる @SubaruG

@Cryolite 確かに，古いコンパイラの実装状況を考えなくていいなら，工夫次第で かなりマトモなエラーメッセージを出せそうですね．