refactor: CWG2518適用を前提として記述する #1260
Conversation
|
@yohhoy @akinomyoga 手が空いているときに見てもらってもいいでしょうか？劇的には変えず基本的には並べ替えているだけに一旦してみました。 |
There was a problem hiding this comment.
構成的には LGTM です。後は細かいことだけ
static_assert文 →static_assert宣言- (元からあったみたいですが) テンプレート宣言時はテンプレート定義時の方がよいのではないかと思います。
- インスタンス化 → 実体化? (このページでは 79fc60a 以前は実体化で統一されていたみたいです)
lang/cpp17/if_constexpr.md
Outdated
|
|
||
| ### `static_assert`文に関する例外 | ||
|
|
||
| 後に述べる2段階名前探索に関する注意点とは関係なく、C++23以降、もしくはCWG 2518が適用された環境においては、template文(もしくは適切な特殊化や`constexpr if`文の中の文)が実際にインスタンス化されるまで、`static_assert`文の宣言は遅延される。 |
There was a problem hiding this comment.
実際にインスタンス化されるまで
表記揺れ。インスタンス化→実体化
template文(もしくは適切な特殊化や
constexpr if文の中の文)
表記揺れ。template → テンプレート? ところで template 文って何のことかよくわからないので具体的にできますか。
CWG 2518 を確認したら、"テンプレート定義時に式が評価された場合は static_assert 宣言は効果がない" と言っていて、別に評価や検証が遅延されるわけではないみたいです。つまり「(2段階名前探索の) 1段階目で false になっても何も起こらない」という形みたいです。
static_assert文の宣言は遅延
「宣言」って書いている時は何を意味していますか? この文書の他の部分ではテンプレートの定義時点のことを宣言と言っているように見えますが、ここでは static_assert の「実体化」もしくは「検証」のことを言っている?
あと「static_assert文」ではなくて「static_assert宣言」のような…。
| 後に述べる2段階名前探索に関する注意点とは関係なく、C++23以降、もしくはCWG 2518が適用された環境においては、template文(もしくは適切な特殊化や`constexpr if`文の中の文)が実際にインスタンス化されるまで、`static_assert`文の宣言は遅延される。 | |
| 後に述べる2段階名前探索に関する注意点とは関係なく、C++23以降、もしくはCWG 2518が適用された環境においては、template文(もしくは適切な特殊化や`constexpr if`文の中の文)が実際に実体化されるまで、`static_assert`文の検証は遅延される。 |
There was a problem hiding this comment.
構文要素としてのstatic_assertは、文(statement)ではなく宣言(declaration)の一種ですね。
There was a problem hiding this comment.
表記揺れ。template → テンプレート? ところで template 文って何のことかよくわからないので具体的にできますか。
これは対応する予定はありますか。P2593R1 の対応する記述に従えば "template 文" ではなくて "テンプレート” でしょうか (edit: lang/cpp11/static_assert.md にも同様のものがありますね)。
There was a problem hiding this comment.
(元からあったみたいですが) テンプレート宣言時はテンプレート定義時の方がよいのではないかと思います。
あと、これについてもご確認いただけたらと思います。
Co-authored-by: Koichi Murase <myoga.murase@gmail.com>
lang/cpp17/if_constexpr.md
Outdated
| ```cpp | ||
| template<bool> struct inferior_static_assert_failure; | ||
| template<> struct inferior_static_assert_failure<true>{ enum { value = 1 }; }; | ||
| #define INFERIOR_STATIC_ASSERT(B) typedef char inferior_static_assert[sizeof(inferior_static_assert_failure<bool(B)>::value)] |
There was a problem hiding this comment.
後続趣旨「CWG 2518未適用のstatic_assertでも同じ問題がある」との直接対比可能な構造にしたいのだと推察しますが、
経緯や結論を知らない読者からすると、複雑な INFERIOR_STATIC_ASSERT マクロの唐突な登場は混乱を招かないでしょうか？
（とコメントしつつ、良い案が思い浮かばず申し訳ない）
There was a problem hiding this comment.
弱い提案：「つまり次の例は意図と異なる挙動を示す。」＋INFERIOR_STATIC_ASSERT 利用例示を削除してしまっても、文意は壊れないと思いました。
（提案適用後の構成）
2段階名前探索における注意点
constexpr if文で、実行されない方のstatementは廃棄文(discarded statement)となり、文の実体化を防ぐ。言い換えると、2段階名前探索における依存名(dependent name)は、廃棄文の場合検証されない。また文が実体化されないのだから通常のif文と同じくもちろん実行時に実行もされない。CWG 2518が適用されていない環境においてはstatic_assertでも同じ現象が発生する。（CWG 2518適用前の
static_assert問題点を指摘する例示コード）
There was a problem hiding this comment.
INFERIOR_STATIC_ASSERTが唐突に過ぎるというのはそのとおりなんですが、これ相当のマクロを自作している古いプロジェクトをC++17対応させたあとに、中途半端に古いコードを良く知らずにコピペしてくるときに引っかかる落とし穴なのかなと思っていました(限定的すぎますよね・・・)。
提案についてはちょっと週末寝かせて考えてみます。
lang/cpp17/if_constexpr.md
Outdated
| @@ -140,51 +194,25 @@ int main() | |||
| } | |||
| ``` | |||
|
|
|||
| `constexpr if`文の条件式内は実体化が起きる。したがって実体化するとコンパイルエラーになるものは書いてはいけない。 | |||
| 上の例では`false_v`を作ったが、ラムダ式でも同様のことができる。ラムダ式はそれが記述された位置から見て最小のスコープ (ブロックスコープ／クラススコープ／名前空間スコープ) で宣言されるクラスとして扱われる。例えば、下の例では`f()`という関数テンプレート内で宣言される。関数テンプレート内のクラスは依存名になるため、テンプレートの宣言時に検証されず、テンプレート実体化まで評価を遅らせることができる。 | |||
There was a problem hiding this comment.
弱い意見：古いコンパイラへに対する回避策提示は、P2593R1 で言及されている信頼性の高い方式1つで十分だと思います。
2.2 Workarounds
As a result ofstatic_assert(false)not working, people turn to workarounds. Which are, basically: how can I writefalsein a sufficiently complex way so as to confuse the compiler?Some of these workarounds actually still do run afoul of the above rule, but compilers aren’t smart enough to diagnose them, so they Just Happen To Work. Checks like: [...]
2.3 Valid Workaround
A more valid workaround is to have some template that is always false (e.g. from this answer):
static_assert(always_false<T>::value);
[...] This is really the only real workaround for this problem, and is something that people have to be taught explicitly as a workaround.
本件に関連する言語仕様解釈は難解なため、条件部にラムダ式を用いる遅延false実装の妥当性について、私個人(yohhoy)は確証をもてません。
There was a problem hiding this comment.
その記述はもともと constexpr if と local struct の評価のタイミングについてでの @yohhoy さんの回答がもとになっていた気がしますね・・・。cppreffjpに書くのを提案したのは私ですが・・・。
回避策として複数あげる必要性が薄らいだのは確かですが、積極的に除去する動機が自分にはないです。
There was a problem hiding this comment.
本コメントの趣旨は「C++言語リファレンスという特性を踏まえると、古い処理系向けの回避策として複数選択肢を提示し読者を迷わせる必然性はない」です。
PS. teratailサイトでの回答を引き合いに出されていますが、これは2018年当時の質問に答えただけです。この部分については私としては困惑しかありません。
There was a problem hiding this comment.
編集方針 - 正確なものに不要な情報はない という話も…。(追記: 個人的にはどっちつかずです)
There was a problem hiding this comment.
時間を開けて読み返した感じ、ないほうがスッキリするので思い切って消しました。うまくハマるように復活させられるならばそういう編集を後の人が行うことを止めるものではありません。
編集方針「正確なものに不要な情報はない」はあるものの、全体の構成として必要性を感じなくなったので除去する。 内容そのものをうまく当てはまる形で復活させられるならばそれに異議を唱えるものではないが、いい方法が浮かばなかった。 ref: - #1260 (comment)
ref
close #1257