tree の構造をいい感じに弄れるところまではできたし既に十分使い物になるんだけど、 shared reference から木構造を弄れるようにすると、今度は走査が面倒になる。たとえば depth-first traversal の途中で木構造が変化してしまうと、出発したノードにイテレータが戻ってこられないかもしれない
で、これをどうにかしたいと思うと tree structure への lock みたいな機能を実装することになる。
そこまでは良いのだが、そうすると木構造を弄る系のあらゆる関数が Result<_, _> を返すか panic しないといけなくなる。
木構造を弄るとき、知らないところでロックされているなどありえないという場面も多々あるし (木を構築中で共有する前なんかが典型例)、一方でロックされていたとき panic せずエラーにしてほしい文脈も簡単に想像できる。
さてどうしたものか
あるいは、単一スレッドからしか触れないのだから、最初の構造弄りで成功した場合はロックされていないことは簡単に確信できるわけで、だったら後続の処理で毎度エラーを確認・分岐させるというのもあまり合理的ではない。
……と考えると、たとえば write lock と read lock みたいなものを用意してそれをトークンとして構造を弄る関数に渡すことで不都合なロックがかかっていない証拠とするか、あるいは「書き込み権限付きのノード参照型」みたいな感じで型レベルで状態を表現できるようにするか、そういう感じの方がユーザ側での煩雑さは減りそうな気がしないでもない。
ただ、ノード参照型を複数用意するとなると、内部実装のロジックについてはリダイレクトできるにせよ、インターフェースやドキュメントの重複を避け難いのであまり気乗りしない
トークン渡す感じにするかなぁ……
あるいは、そのトークンと tree 自体へのハンドルを融合させてしまって、あたかも arena tree の編集で必ず arena への参照が必要かのごとく、ノードの参照ではなくトークン付きの tree への参照の方に .insert() とか .remove() 的なもの (こういう名前にはしないが) を生やすという手もある
ただ、せっかくノードの参照単独で所属する木を意識することなく直観的な構造の編集ができるというメリットを潰すことになりかねないというのがなぁ。理想的には A.append(B) で A と B の所属する木が何であろうが関係ないし、やることやってくれという感じだよな。