言語機能のページタイトルを、具体的な変更が内容がわかるよう改善する

[faithandbrave]

• cpprefjp雑談部屋 #1273 (comment)

わかりにくいページタイトルを見つけて改善案を考えていきたいです。
問題指摘が落ち着いたら修正してクローズします。

C++11

わかりにくい	改善案	備考
auto	変数の型推論auto
decltype	式の型を取得するdecltype
一様初期化	波カッコを使用したコンストラクタ呼び出し構文
ラムダ式	関数オブジェクトをその場で記述するラムダ式
noexcept	例外送出しないことを宣言するnoexcept
constexpr	汎用化した定数式constexpr
nullptr	ヌルポインタ定数nullptr
共用体の制限解除	共用体でクラスオブジェクトをもつことを許可
テンプレートの右山カッコ	テンプレートでの連続した右山カッコを許可
エイリアステンプレート	テンプレートを使用した型の別名定義
char16_tとchar32_t	Unicode規定の文字型としてchar16_tとchar32_tを追加
alignas	アライメントを指定するalignas
alignof	アライメントを取得するalignof
long long型	64ビット以上の整数型long long

C++14

わかりにくい	改善案	備考
decltype(auto)	参照も考慮した型推論decltype(auto)
constexprの制限緩和	constexpr関数内での条件分岐とループの文を許可
[[deprecated]]属性	非推奨を宣言する[[deprecated]]属性

C++17

わかりにくい	改善案	備考
十六進浮動小数点数リテラル	16進浮動小数点数リテラル	2進数リテラルと合わせた
インライン変数	ヘッダファイルでの変数定義のためのインライン変数
構造化束縛	関数の戻り値を分解・展開する構造化束縛	戻り値には限らないのだけど簡易表現
波括弧初期化の型推論の新規則	単一要素の波カッコ初期化を非配列とする
[[maybe_unused]]属性	使用しない変数を宣言する[[maybe_unused]]属性	宣言…でいいかなぁ
[[nodiscard]]属性	戻り値を無視すべきでないことを宣言する[[nodiscard]]属性
厳密な式の評価順	式の評価順を厳密に規定
[[fallthrough]]属性	意図したフォールスルーを宣言する[[fallthrough]]属性
constexpr if文	コンパイル時の分岐文if constexpr	constexpr ifとif constexprで編集合戦になったのでissueで決めたい
範囲 for ループの制限緩和	範囲for文のイテレータ型が一致しないことを許可
__has_include	インクルードファイルの存在チェック__has_include

C++20

わかりにくい	改善案	備考
一貫比較	比較演算子の自動定義
コンセプト	テンプレートパラメータの制約
即時関数	常に定数式評価するconsteval
コルーチン	関数実行の中断・再開を制御するコルーチン

C++23

わかりにくい	改善案	備考
if consteval	コンパイル時かどうかで分岐するif consteval

[akinomyoga]

提案を見た時は良さそうに思ったのですが、実際に例を見てみるとわかりにくく感じます。多くが修飾構造的に「<説明>な<用語>」になっていますが、これは「<用語> の中でも特に特別な場合として <説明> に当てはまる物が追加された」というように見えます。つまり意図としては 「<用語> (:= <説明>)」ということなのだと思いますが「<用語> ∩ <説明>」に関する記事に見えます。

「<用語> (<説明>)」や「<用語> ～<説明>～」のような形の方がいいなと個人的に思うのですがいかがでしょうか。

例: decltype (式の型を取得)

わかりにくい	改善案
一様初期化	波カッコを使用したコンストラクタ呼び出し構文

あとこの様に用語自体もなくしてしまう形だと、逆に用語についての説明を求めて入ってくる人が見つけられなくなってしまうのでよくない気がします。個人的には用語も残していただけるといいなと思います。タイトルが長くなってしまうかもしれませんが、個人的にはタイトルは長くてもいいかなと素朴に思います。

[yohhoy]

あとこの様に用語自体もなくしてしまう形だと、逆に用語についての説明を求めて入ってくる人が見つけられなくなってしまうのでよくない気がします。個人的には用語も残していただけるといいなと思います。

上記同意です。例えば「コンセプト」や「一様初期化」といったC++固有用語(Term)は、一定の市民権を得ているものも多いですし、タイトルとして記載されている状態が好ましいと思います。

---

言語機能ページタイトルは大きく2種類に大別される気がしており、それぞれで対応方針を分けてもよいのではないでしょうか。

• 新しい機能導入：「auto」「ラムダ式」「コンセプト」「構造化束縛」など
  • 原則はその言語機能名だけのページタイトルとする。ページ冒頭の本文説明を数行読めば、意味をとれると期待できる。
• 既存機能の改善：「共用体の制限解除」「テンプレートの右山カッコ」「constexprの制限緩和」など
  • 利用者視点に基づいた説明的なページタイトルに変える。

[yumetodo]

新しい機能導入か既存機能の改善かはだいぶ主観にはなりそうで明文化が難しいですが主要な執筆者なら概ね切り分けられると思うので良さそうに思えます。

[faithandbrave]

SEO (検索エンジン最適化) 的にはページタイトルが最も効く、という事情があるので、ユーザーが目的のページに辿り着きやすいように、新しい機能の導入でも補足情報はタイトルに入れてもいい気がします。

[tshino]

説明対象に名前（用語でも通称でも）が付いている場合はそれをタイトルにして、あわせて補足的に説明も付加する（括弧書きや「～○○～」）案に賛成です。
言語機能の仕様変更であってもそれ自体に名前が付いていればその名前を用い、説明も付け、
一言で言い表すような名前がなければ、シンプルに説明だけをタイトルにするのが良いと思います。

[akinomyoga]

既存機能に対する変更と区別するという @yohhoy さんの案に同意です (というか、元より <用語> (<説明>) や <用語> ～<説明>～ というのは、新しい機能導入に該当する記事についてだけ言っているつもりでした… 改めて自分のコメント見たらその事ちゃんと書いてませんね…)。

既存機能に対する変更や追加の機能については括弧書きよりも <説明>な<用語> や <用語> を云々 のような形が良いと思います。

ところで auto は新しい機能導入ではあるけれども、昔の auto とは違う意味での導入なので 変数の型推論としての auto などでも良いかもしれない。微妙なところですが… (そもそも昔の auto を使っている人いたのか怪しいですし)。

[yumetodo]

変数の型推論としての auto

通常関数の戻り値型推論 と対比関係に持ち込めるかとちょっと考えましたがそこまでしなくていいか

[faithandbrave]

それでは一旦、変更案をまた考えてみます。