問題タブ [c++14]

式に SFINAE と decltype auto を混在させることはできますか?

-std=c++1y を使用して、g++ でサポートされている戻り値の型の推論で遊んでいます。
明示的な戻り値の型を使用して関数のプロトタイプを作成し、後で戻り値の型推定を使用して関数を定義しようとすると、コンパイラはあいまいな古い宣言について警告します。

これが機能しない正当な理由はありますか？
定義で戻り値の型推定を使用する理由は、コードをクリーンに保ちながら、自己文書化の理由からプロトタイプに明示的な型を必要とするためです。戻り値の型の推論を使用する場合と使用しない場合のベストプラクティスに関する推奨事項をいただければ幸いです:)

より明確にするために、次の回答をお願いします
。 1. これはコンパイラの実装ミスですか? (そうではないことはかなり確信しています)
2. この種の控除を行うことはできますが、標準への提案では許可されていませんか? もしそうなら、なぜですか？
3. これが本当にあいまいである場合、型を推測し、それを明示的な前方宣言と一致させようとすると問題が発生する例は何ですか?
4. この背後には、より深い実装固有の問題がありますか?
5. 単なる見落としですか？

これは、Andrei Alexandrescuの投稿から着想を得ています。

次の方法で式を初期化することの長所と短所は何ですか? いつどちらを優先する必要がありますか?

私のクラスのインターフェースには、存在しないかもしれないオブジェクトへのアクセサが含まれています。現在、null の可能性があるポインターを返します。ポインターをここでstd::optional提案されているように置き換えたいと思います。アクセサーには、Meyers の const_cast トリックを使用して同じコードを 2 回繰り返さないようにするオーバーロードがあります。const

要するに、これを置き換えたい：

これとともに：

次の理由により、交換は満足のいくものではないようです。

1. ブランチを紹介します。
2. 追加の複雑さは、オーバーロードを軽量にするという目標を幾分無効にします (そして、コンパイラによって自明に最適化されます)。

私はstd::optional、参照の特殊化は基本的に、安全性が追加されたポインター以上のものに要約できると想定しているため、ポインターソリューションの単純さを維持する方法があるかどうか疑問に思っています。使用するアクセサ オーバーロードを記述するより満足のいく方法はありますstd::optionalか?

これは、リンクされたワーキングペーパーに記載されていない、クラス内のフレンド関数の戻り値の型推定に関する小さな実験です (両方のケースで Clang 3.4 SVN と g++ 4.8.1 を使用)。std=c++1y

ライブの例。

質問: C++14 でサポートされているクラス内のフレンド関数の戻り値の型の自動推論はサポートされていますか?

私は C++ のちょっとした言語拡張について考え、提案のドラフトを書きました ( http://pdfcast.org/pdf/user-defined-type-qualifiers-1 )。

アイデアは、ユーザーが const や volatile などの修飾子を自分で定義して、修飾するコード (つまりメソッド) が同じ修飾子のみを呼び出すようにすることです。

問題は、これが言語規則と衝突するかどうか、または何かを見逃していないかどうかです。