cpprefjp / site

cpprefjpサイトのMarkdownソース
https://cpprefjp.github.io/
368 stars 152 forks source link

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

Open faithandbrave opened 1 month ago

faithandbrave commented 1 month ago

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

C++11

わかりにくい 改善案 備考
auto 変数の型推論auto
decltype 式の型を取得するdecltype
一様初期化 波カッコを使用したコンストラクタ呼び出し構文
ラムダ式 関数オブジェクトをその場で記述するラムダ式
noexcept 例外送出しないことを宣言するnoexcept
constexpr 汎用化した定数式constexpr
nullptr ヌルポインタ定数nullptr
共用体の制限解除 共用体でクラスオブジェクトをもつことを許可
テンプレートの右山カッコ テンプレートでの連続した右山カッコを許可
エイリアステンプレート テンプレートを使用した型の別名定義
char16_tchar32_t Unicode規定の文字型としてchar16_tchar32_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 ifif constexprで編集合戦になったのでissueで決めたい
範囲 for ループの制限緩和 範囲for文のイテレータ型が一致しないことを許可
__has_include インクルードファイルの存在チェック__has_include

C++20

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

C++23

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

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

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

例: decltype (式の型を取得)

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

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

yohhoy commented 1 month ago

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

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


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

yumetodo commented 1 month ago

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

faithandbrave commented 1 month ago

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

tshino commented 1 month ago

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

akinomyoga commented 1 month ago

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

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

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

yumetodo commented 1 month ago

変数の型推論としての auto

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

faithandbrave commented 1 month ago

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

faithandbrave commented 3 weeks ago

変更案を見直しました。これでいかがでしょう。

C++11

変更前 改善案 備考
auto 変数の型推論のためのauto 自動変数のautoがあったので完全な新キーワードではなかった
共用体の制限解除 共用体でクラスオブジェクトをもつことを許可
テンプレートの右山カッコ テンプレートでの連続した右山カッコを許可

C++14

変更前 改善案 備考
constexprの制限緩和 constexpr関数内での条件分岐とループの文を許可

C++17

変更前 改善案 備考
十六進浮動小数点数リテラル 16進浮動小数点数リテラル 2進数リテラルと合わせた
波括弧初期化の型推論の新規則 単一要素の波カッコ初期化を非配列とする
厳密な式の評価順 式の評価順を厳密に規定
範囲 for ループの制限緩和 範囲for文のイテレータ型が一致しないことを許可

C++20

変更前 改善案 備考
一貫比較 比較演算子の自動定義 会話でこのキーワードがでたりはしないので
即時関数 常に定数式評価するconsteval 同じく
yohhoy commented 2 weeks ago

faithandbraveさん新案に対して、(弱い)改善提案です:

現:一貫比較 案:比較演算子の自動定義

新しい <=> 演算子もページタイトルに現れるとうれしいかなと思い、「<=>による比較演算子の自動定義」とかはいかがでしょう。

akinomyoga commented 2 weeks ago

波括弧初期化って何の訳だろうと思ったのですが braced-init-list からの類推による独自の呼び名ですか? リスト初期化 (list-initialization) にしませんか。

と思ったのですが "波カッコ初期化" だと幾つか用例があるのですね。。

ただし対応する C++11 の記事の名前は提案文書のタイトルから取って一様初期化 (uniform initialization) になっています…が多分これはこれまでの初期化をもっと一様にしましょうという "動き" につけられた名前みたいな雰囲気で、実際に導入された機能の名前ではない? こういうのはどちらの名前にしたら良いのかは際どいところですね。一様初期化と呼んでいる所も幾つかありますね。

faithandbrave commented 2 weeks ago

<=>による比較演算子の自動定義

==による!=の自動定義も含まれますが、メインテーマとして<=>を記載する、というお考えでしょうか?

faithandbrave commented 2 weeks ago

リスト初期化にしなかったのは、vector<T> v = {a, b, c};と区別したかったからなのですが、、、どうしましょうね。。。 規格用語に必ずしも従う必要がないのは、data memberをメンバ変数と言ってる前例がありますが。

一様初期化は、機能名に変えてしまってよいと思います。 エイリアステンプレートも、提案としてはTemplate Aliasesですが機能名をページ名にしています。 https://cpprefjp.github.io/lang/cpp11/alias_templates.html

yohhoy commented 1 week ago

<=>による比較演算子の自動定義

==による!=の自動定義も含まれますが、メインテーマとして<=>を記載する

Oh... 「==からの!=自動導出」は失念していました。確かに悩ましいですね。

シンプルな 元案1. か、全部盛り込んだ 案4. のいずれかを推します。

  1. 比較演算子の自動定義(元案)
  2. <=>による比較演算子の自動定義
  3. <=>演算子と比較演算子の自動定義
  4. <=>/==による比較演算子の自動定義
yumetodo commented 1 week ago
  1. 比較演算子の自動定義(元案)
  2. <=>による比較演算子の自動定義
  3. <=>演算子と比較演算子の自動定義
  4. <=>/==による比較演算子の自動定義

横からですが、4 > 1 >> その他 かなという印象です

faithandbrave commented 1 week ago

私も4がいいかなと思いました。そうしましょうか。 リスト初期化については、進展なければ一旦保留ということで。。。