cpprefjp雑談部屋

[faithandbrave]

cpprefjp雑談部屋ルール

• issueに起こすほどでもない雑多な議論をする場所です
• 通知がうるさいと感じた方は、issue個別で通知をオフにできるので、そちらをご利用ください
• 個人のつぶやきをゆるく投稿してもらってOKです
• cpprefjpメンバー以外の投稿も歓迎します
• X/Twitterなど、ほかの場所で発せられたcpprefjpの問題などがあったら、ここで教えてください (issueを起こしてもらってもOKです)
• ここで始まった話題で詳細な議論が必要になってきたら、ぜひissueを起こして移動してください
• 専門分野ごとの部屋が必要になってきたら、部屋を分けることを検討します
• 質問掲示板というわけではないので、回答が得られることは期待しないでください
• だれかが議論していても、気にせず別な話題を投稿してください
• 攻撃的な批判、ハラスメント行為、ヘイトなどは禁止とします

[wx257osn2]

だれかが議論していても、気にせず別な話題を投稿してください

前の議論が終わるのを待つのもアレなのでこれはそう運用されるべきというのは同意した上で、GitHub issueのUIでやるの結構大変そうだなという気持ちに…(GitLabみたいにスレッド形式だと同じ話題だけまとまって話せるんですけどねぇ…)(まぁある程度話が盛り上がってきたら別途issue切って引っ越しましょう、でなんとかなるかな)

[faithandbrave]

一旦はアクティブユーザー数がそんなに多くないだろうという想定で、試しに運用してみる、という感じですかね

[onihusube]

話題提供

3月に行われた東京でのWG21会議のトリップレポートがいくつか

• 2024-03 Tokyo ISO C++ Committee Trip Report — Third C++26 meeting! 🗼 : r/cpp
• Trip Report: Winter ISO C++ Standards Meeting in Tokyo | by David Sankel | Apr, 2024 | Adobe Tech Blog

大きな機能の追加はなさそうですが、個人的体感としては値ベース静的リフレクション（P2996）がにわかに盛り上がりつつあるのを感じています。

[yohhoy]

C++標準ライブラリでの[[nodiscard]]属性付与に関する P3201 もAprovedされたのですね。今後は nodiscard指定されることは原則なさそう...（既存関数はそのままかな？）

[onihusube]

P2422R0 Remove nodiscard annotations from the standard library specification

が採択されると全部消えそうですね

この場合cpprefjp的には備考かどこかにこの関数は実装によって[[nodiscard]]指定される場合がある、みたいに書くことになるんですかね

[faithandbrave]

リフレクションはstd::metaライブラリだけかと思ったら、^とか言語機能もいろいろ入るんですね

[onihusube]

リフレクション、機能そのもののことと^Tすることと^Tして得られたmeta::infoのことをそれぞれreflectionって呼んでて、訳語大変そうだなって思ってます
というかややこしい・・・

[faithandbrave]

https://cpprefjp.github.io/lang/cpp26/user-generated_static_assert_messages.html

ページタイトルにもキーワードリンクが貼られるのですが、これをよしとするかどうか、悩ましいところです

[akinomyoga]

記憶余り定かじゃないですが、たしか、最初は見出しには適用しないようにして PR 作ったのですが、その後で誰かの指摘により見出しにも適用するように変更したような…。

[faithandbrave]

見出し2以降は、キーワードリンクがあると便利な気はしますね

[akinomyoga]

すみません。経緯が少し違いました: cpprefjp/markdown_to_html#5 の時点では見出し除外 (akinomyoga/cpprefjp-markdown_to_html@a9086f4) は入っていました。その後で修正 cpprefjp/markdown_to_html@8f04104 が入っていますね (この追加変更は何となく記憶にあったのですが、実際に議論があったのだったかそれとも個人的に commit を見て知ってただけだったのか分かりません)。(追記: うーんでもやっぱり見出しにも適用した方が良いみたいな議論がどこかであったような気がします…が脳が勝手に作り出した虚偽記憶の可能性も…)

見出し2以降は、キーワードリンクがあると便利な気はしますね

そうですね。でしたら、該当箇所に h[2-6] h1 (訂正: ごめんなさい逆でした) を戻すだけで良さそう(?)ですね。

[faithandbrave]

かんたんに直せそうなので、h1は除外してみます！

[faithandbrave]

直しました！
cpprefjp/markdown_to_html@533bf5f

[wx257osn2]

@akinomyoga

うーんでもやっぱり見出しにも適用した方が良いみたいな議論がどこかであったような気がします

見つけました！ #774 (comment) (複数リポジトリのissueだったりMRだったりに議論がとっ散らかってるから過去の議論を追いかけるのが中々大変ですね…)

[wx257osn2]

過去の議論を追いかけるのが中々大変

GitHubはコミットに対してコメントが付けられることを思い出したので，試しにコミットから関連コメントへのリンクをはってみました いつか何かで遡ったときに議論が少しは追いやすくなりそう cpprefjp/markdown_to_html@533bf5f#commitcomment-141949065 cpprefjp/markdown_to_html@8f04104#commitcomment-141949048

[akinomyoga]

おー、ありがとうございます! リンクのコメントもありがとうございます!

本来は (PR を介さずに) 議論の末に追加された変更に関してはできるだけ commit message に関連するリンク (単なる #番号 などではなくフルの URL) を入れておくのが良いですね。

[wx257osn2]

そうですねぇ，ただ実際うっかりコミットメッセージにURL含めるの忘れてた！みたいなことは私もやりがちなので…(PR経由だとPR側にコメント残すなどでコミットからでも2hopでアクセスできることはわかっていたのですが，直接コミットでの取り返しの付け方が今まで(私が)わかってなかったのですよね)

[akinomyoga]

私も前から git で後付け注釈を入れられる仕組みはないのかと何となく思っていたのですが、今調べたら git notes というものがあるみたいですね。

• git notes でコミット自体を変更せずに git に注釈を残す #Git - Qiita
• Git - git-notes Documentation

でも GitHub でのサポートは削除されたみたいです。理由はよく分かりませんが、たぶん色々と問題があるのでしょう。Commit hash で紐づけてるみたいなので、(勝手な予想ですが) rebase とか filter-branch とかしたら紐づけが切れそうですし、異なる複数の branch に cherry-picked された元々同じ commit にも反映されなそうですし…。

[yumetodo]

https://twitter.com/wx257osn2/status/1610601153292828672

cpprefjpにどう立てつければいいかは浮かんでないですが、constexprみたいに初期仕様からドラスティックに仕様が変わっていったものを複数ページ見てマージして読むのはやっぱり辛いかもしれない、と思いました。

[ToruNiina]

yumetodoさんのコメントと関連するのですが、私個人も似たような経験を何回かしていて、例えばどのattributeがどの時点で入ったかなどを簡単に確認したいときなどに年表のようなものがあると嬉しいと考えていました。

具体的には、各言語機能のページ（lang/cppXX）にある表の項目（「定数式」など）ごとにページを立てて、バージョンごとに節を作って対応する言語機能の表をコピーしてきて並べるだけでもそれなりに役に立つのではと考えています。もちろん、年表ページに行って表を眺めなければならない、という点でわかりやすさは言語機能の個別ページを書くよりも劣るでしょうが、コスト面で一考の余地はあるかと思います。

内容がほぼ既存のものの切り貼りで済み、ページの内容もほぼ表だけで短いので、「constexpr」のようなページを新たに作成して変遷の説明を書くことと比べると手間はかなり少ないはずです。メンテコストは少し上がってしまいますが、基本的に過去のバージョンにおける機能追加の数は増減しないと考えてよいので、言語機能の記事を追加する際にしか影響はないはずです（とはいえ言語機能の記事を書く時点でコストが高いので追加コストは避けるべき、という意見もあるかとは思います）。

ただ、パッと見バージョンごとに表の切り分けの粒度が少し違うように思えるので、それに応じて既存の言語機能ページの表の項目わけを少し調整する必要は出るかもしれません。

[faithandbrave]

おそらく表だけであればすでにあるかと思います。

cpprefjpで初出の言語機能ページには、関連項目としてその機能に関連するアップデートへのリンクを記載しているので辿れるようになっています。

• https://cpprefjp.github.io/lang/cpp11/attributes.html
• https://cpprefjp.github.io/lang/cpp11/lambda_expressions.html
• https://cpprefjp.github.io/lang/cpp11/constexpr.html

yumetodoさんがリンクを貼られた先の問題としては、constexprの初出ページで「できない」と書かれていたことが後のバージョンでは「できる」に変わっており、初出ページ内で書いてあることだけ読んでも、現在使っている言語バージョンでできることがわからない、ということかなと思います。
問題として理解はできますが、結局この問題は、対象となる言語機能のすべての仕様が書かれたページを用意しないと解決しない気がします。

それはいずれやらないといけない気はしますが、私には当面、余裕がないですね。
なので、リファレンス作成に余裕ができるか、完成のために尽力できる方がでてきて差分ではない言語機能の解説に取り組む表明をすれば、話が進むと思います。

[tshino]

言語機能のページタイトルの横に「C++11」などと書いてありますが、
そのC++バージョン以降でずっと通用するという誤解が生じやすいのは分かる気がします。

「このページはC++11時点での言語機能を解説しています」
「のちの規格で変更されている場合があるため関連項目を参照してください」

みたいな注意書きの定型文章をページの最初の方に書くのはどうでしょう？

[faithandbrave]

「このページはC++11時点での言語機能を解説しています」
「のちの規格で変更されている場合があるため関連項目を参照してください」

これは暫定対応としてすぐにでき、ある程度の効果も期待できるので、よい気がします。
ページタイトルの下、概要の上に全ページ、機械的に載せてしまっていい気がします。
あとは、「## 関連項目」にアンカーをつけてページ内リンクを貼る、とかでしょうか。

あとは、以下のような対応も追加で検討してみましょうか。

• 言語機能のページタイトルを提案文書の直訳的なものから、機能的・説明的なものにできるだけ変更する
• 関連項目を箇条書きではなく表にしてページタイトルからは読み取れない情報を補完するか、箇条書きをネストして情報補完する

例として、C++14の「constexprの制限緩和」ページは、どう緩和されたのかページタイトルだけではわからないので、「constexpr関数内での条件分岐とループの文を許可」などのページタイトルに変更することが考えられます。
ページタイトルの変更だけでは対応しきれないものがあった場合に、表もしくは箇条書きのネストを検討するのでどうでしょう。

一旦は、「ページタイトルから具体的な変更内容がわかりにくいページを探す」issueを立てて、一通りチェックしてみるのはいかがでしょうか。

[akinomyoga]

「このページはC++11時点での言語機能を解説しています」
「のちの規格で変更されている場合があるため関連項目を参照してください」

これは暫定対応としてすぐにでき、ある程度の効果も期待できるので、よい気がします。

よいと思いますが、例えば同じ C++11 の提案の間でも、初期の提案で取り込まれたものが後の提案・修正で変更されることもある(提案の内容がそのまま C++11 の確定した振る舞いになっているとは限らない) ので文言は調整した方が良い気がします。たとえば

「このページはC++11規格原稿に取り込まれた変更を解説しています」
「他の変更で上書きされている場合があるため関連項目を参照してください」

(あまり深く考えていないのでまだ問題があるかも)

---

ページタイトルには提案文書・バグ修正の番号 (複数関連するものがある場合は一番最後のもの) も付記されていると、例えば Web の検索結果一覧から特定しやすくて良いなと思います。

[faithandbrave]

ページタイトルに提案文書の番号をつけるのは、タイトル末尾に以下のようにつけるのでどうでしょうか。先頭だと、Web検索結果で最も見せたいであろうタイトルが切れてしまう懸念があります。

「符号付き整数型が2の補数表現であることを規定 [P1236R1]」

[akinomyoga]

ありがとうございます! その形式で良いと思います!

[yumetodo]

目を離した隙に一気に話が進んでました・・・。

そうですね、今だと初見ではそのページに加えて何を読むべきなのか見抜けない可能性があるので、そういう警告をつけるのはいいかもしれません。

[yumetodo]

ページタイトルには提案文書・バグ修正の番号 (複数関連するものがある場合は一番最後のもの) も付記されていると、例えば Web の検索結果一覧から特定しやすくて良いなと思います。

提案文章番号、たしかに・・・。言われてみれば例えばコンパイラの実装状況見に行くときも提案文章番号でgrepしますからそのほうがいいですね。

[faithandbrave]

• のちのC++バージョンの言語仕様も確認するよう促す #1275
• 言語機能のページタイトルを、具体的な変更が内容がわかるよう改善する #1276

2件、issue化しました。
issue化したものはそちらに議論を移動お願いします。
issue化できていない議論があれば、継続をお願いします。