{名称空間 K#F85E/A-4686-5D3F}

デライト最終調整，KNEST 認証整理。

睡眠・食事を取り，作業再開。

途中で終了。

本日中の「デライト手定め離立」を目指す。これまで「デライト先行離立」と呼んでいたものとほとんど同じだが，表現を厳密化した。

Cμ で型変換を統一的に扱うため，これまで活用していなかった to_ 接頭子を活用することにした。構築子，構築函数や to 演算子と中途半端に被る気がして避けてきたが，拡張性・柔軟性・明示性が高く変数名・名称空間との衝突も避けられるため，s_T のような複合型ではこちらを標準的に利用した方がいいだろう。

Cμ の名称空間，台録構成の方針について整理が進んだ。

型に関する函数と名称空間の関係について，foo が単純型の表現である場合は foo() を変換函数に，複合型の表現である場合は foo_T() を変換に利用し，必要であれば foo:: を関連函数などをまとめる名称空間として利用することを明文化することにした。

もともと，自然にやっていたことではあるが，改めて検証してみると意外に合理的だったことが分かった。

これら規約を Cμ 標準名称空間規約，Cμ 標準譜台規約として管理していくことにした。

希哲14年1月13日，これまでの経験則を明文化する形でまとめ始めた。

foo_T に対する foo は名称空間として利用してもいい。

デライト最終調整，KNEST 認証整理。

途中で終了。

結局，Cμ における名称空間と函数の衝突は単純型に対応する名前は函数に，複合型に対応する名前は名称空間とすることを明文化して解決。

デライト最終調整，KNEST 認証整理。

途中で終了。

Cμ における台録構成と名称空間について方針を再確認。

もともと，名称空間を切り分けやすくしたい，ADL を効率的に利用するために foo_T を foo:: 以下に入れ，冗長性は use で解決するという方法を取っていたが，これはいまだに有用であるため，据え置くことにした。

一方，これに合わせて foo/ に foo.cl.h を入れる，というような方法は煩雑さの方が大きいため，廃止することにした。これは定義位置ではなく，通称を基準に考えることで整合性を取る。既存の譜類は順次移動させる。

foo:: と foo() が衝突する問題をどう回避するかという課題は Cμ 初期からずっと残っているが，今のところそれほど大きな障害にはなっていないため解決は急がないことにした。

C++ は参照内容によって foo が名称空間か函数か解決してくれるような気の効いた仕組みにはなっていないため，foo を名称空間として利用するか函数として利用するかは設計の問題と考えるしかないかもしれない。

これまで，数値への変換は n() で，文字列への変換は s_T() で行うことが多く，整合的ではない気がしていたが，よく考えると単純型と複合型の使い分けとして合理的だったのかもしれない。s_T には s:: があった方がいいが，n:: の必要性は感じたことがない。

デライト最終調整，KNEST 認証整理。

tp.h のまとめを終えたところで終了。

今日はここまで。

今日は Cμ 交度規約についてもいくつか進展があった。

これまで制御構造の波括弧省略は避けてきたが，「書き始めは波括弧付きで，安定してきたら外す」という規則を導入することで，不安定な時期には波括弧付きで安全性を高め，外す余裕のある程度に安定した時期には外して可読性を高めていくことにした。行頭カンマ・行末カンマ使い分けの経験が役立った。

また，多層的な名称空間を利用する際の問題だった字下げが深くなり過ぎるという問題について，次行の開き波括弧の位置を上げても良い，という規則を導入し，これを「字上げ」と呼ぶことにした。細かい法則については実験しながら決めていく。

あとは，苦手意識が残っていたテンプレートについて良い復習が出来，今後の応用力につながりそうだ。

もう一つ面白い実験として，字下げならぬ「字上げ」というのを Cμ 交度（コーディング）規約に導入してみた。部区（ブロック）の入れ子が深くなり過ぎた場合，次行の波括弧を上げて調整しても良い，という規則。これはどこまで適用するのが良いか微妙な所だが，少なくとも Cμ の名称空間では使えそうだ。