Serdeはやろうと思えば大抵のことが出来て偉大だと思うけど、少し凝ったことをしだすと型を定義してトレイト実装を手書きすることになって記述が増えがち。いや、典型的なケースでは手続きマクロなどで非常に簡潔に書けるし、そういう少し凝ったことなんて頻繁にするものでないというのはそれはそうなのだけど

API設計の一般論としてはトレイト実装の手間を減らすためにクロージャからトレイトを実装した値を作る手段（e.g. `iter::from_fn`）を提供するのが定石だけど、`DeserializeSeed`は`impl Deserializer`に対して多相である必要があるし、`Visitor`はメソッドが多すぎるし、というかこれもエラーや`{Map,Seq}Access`に対して多相である必要があるしでクロージャでは上手く表現できないよなあ

`Visitor`のメソッドが多い問題は実装できる`visit_*`系のメソッドを1種類に限定して、クロージャに加えて`expecting`を実装するための`impl Display`を受け取れば済む話か。さらにエラーは返せないものとして、`{Map,Seq}Access`についてはエントリ／要素に対する`fold`的な処理として表現させれば良さそう？　エラーを返せないのはちょっと厳しいかしら

`Visitor`が`impl de::Error`に対して行うべき操作はコンストラクションのみだから、型消去されたファクトリ的なものを渡せたりするかしら？　あるいは`invalid_value`などのセマンティクスは諦めて単に`String`を返させて`Error::custom`に突っ込むか

うーむ、どうも`lists/members/create_all`で大量のアカウントを追加しようとすると一時的に何らかの制限がかかるっぽい？　先ほど`lists/members/create`で1件だけ追加するのに成功したけど、続いて`create_all`で100件弱追加しようとしたら上手くいかず、その後は`create`も403を返すようになった（Twitter APIの話）
QT: https://fedibird.com/@tesaguri/109731628539032895 [参照]

うおおおお、この実験はTwitterの利益にもなるであろう理論を実証するものぞ。道を開けい（？）。というかドキュメントに書かれていない制限を課さないでください