本サイトでは、サンプルコードでのADL使用について、とくにルールがありませんが、リフレクションについては複数のADL可能な機能を組み合わせる例が多いのと、実際にユーザーが書く場合にはADLを多用することになることが考えられます。
一方でリファレンスサイトとしては説明的なコードが望ましく、理解しやすさ、説明のしやすさのために、冗長なコードがより好ましい可能性もあります。
そのうえで、このIssueではリフレクションに関してサンプルコードでのADL使用の方針を考えたいと思います。
方針1. 主役となる機能だけ完全名を記載する
リファレンスページの該当機能、それと列挙子の文字列化だったらenumerators_ofとidentifier_ofは完全名にする
方針2. できるだけADLを使う
実際にユーザーが使う場合にはできるだけADLを使うことを想定して、サンプルコードの主役の機能とか関係なく、できるだけADLを使う。
コードブロック中の識別子にリンクはつけるが、必要に応じてコメントや説明文を書く。
方針3. 頻出する機能にADLを使う
たとえばstd::define_static_array / identifier_ofのようなよく使う機能にはADLを使用し、それ以外の機能は重要なものだとして完全名を記載する。
また、ユーザーガイドとして、リフレクションに関してADLが効く機能・効かない機能について、リフレクションのページに記載するのがよさそうな気はします。
引数なしの関数であるaccess_context関係はADLが効かないのと、std::meta::infoも関数ではなくクラスなのでADLは効きません。
ご意見お待ちしておりますー。
本サイトでは、サンプルコードでのADL使用について、とくにルールがありませんが、リフレクションについては複数のADL可能な機能を組み合わせる例が多いのと、実際にユーザーが書く場合にはADLを多用することになることが考えられます。
一方でリファレンスサイトとしては説明的なコードが望ましく、理解しやすさ、説明のしやすさのために、冗長なコードがより好ましい可能性もあります。
そのうえで、このIssueではリフレクションに関してサンプルコードでのADL使用の方針を考えたいと思います。
方針1. 主役となる機能だけ完全名を記載する
リファレンスページの該当機能、それと列挙子の文字列化だったら
enumerators_ofとidentifier_ofは完全名にする方針2. できるだけADLを使う
実際にユーザーが使う場合にはできるだけADLを使うことを想定して、サンプルコードの主役の機能とか関係なく、できるだけADLを使う。
コードブロック中の識別子にリンクはつけるが、必要に応じてコメントや説明文を書く。
方針3. 頻出する機能にADLを使う
たとえば
std::define_static_array/identifier_ofのようなよく使う機能にはADLを使用し、それ以外の機能は重要なものだとして完全名を記載する。また、ユーザーガイドとして、リフレクションに関してADLが効く機能・効かない機能について、リフレクションのページに記載するのがよさそうな気はします。
引数なしの関数である
access_context関係はADLが効かないのと、std::meta::infoも関数ではなくクラスなのでADLは効きません。ご意見お待ちしておりますー。