らりお (進捗垢) @loliconductor@mastodon.cardina1.red

まあ、関数の境界を越えてメンバ変数単位でのチェックをしてほしいかといえば、そうは思わないけど……
(もしそうなると、どのメンバ変数が必要かは関数の型から読み取れない情報になってしまうので)

より正確には、 f 中で self の一部が mutably borrowed になってしまい、 try_recover が self 全体を借用したがるため、うまく辻褄を合わせられない。
関数を境界にして部分的な借用が self 全体の借用になる

たとえば
impl Foo { fn f(&mut self) -> Result {...} }
みたいなメソッドがあったとして、その中で Foo のメンバ変数を mutable に借用している場合、
Foo::try_recover<T, E>(&self, result: Result<T, E> { ... }
みたいなのがたぶん借用チェックに引っ掛かるのよね (self が mutably borrowed なので)

条件付きでエラーから復帰するようなコードがどうにも綺麗に抽象化できないんだけど、 borrow の調整が難しいのも一因ではありそうに思えてきた

rustc: Implement incremental "fat" LTO · Issue #58378 · rust-lang/rust
https://github.com/rust-lang/rust/pull/58378

おぉ

美しくないコードなら書かない方がマシ症候群を発症したので、 fbxcel の DOM 機能周辺のエラー処理が綺麗になるまで機能追加は行われません

これで FBX が複雑怪奇で読むに堪えないとかであれば諦めもついたんだけど、残念なことにというべきかそれなりに読めてしまっている

まあ COLLADA と FBX どちらがマシかと言われるとやはり悩ましいし気持ち的にはオープンな COLLADA の方が好ましいのだが、事実として COLLADA で出力されたかわいい女の子はほとんどなくて FBX にはそれなりにある

今日日 XML も流行らないだろうなぁ…… (COLLADA 処理系を作ろうとして懲りた顔)

そんな形式があったのか……存在も知らなかった

はいはいわかった

むりじゃんイテレータなかったワロタ

set.iter().inspect(|v: &mut i32| v += 1);
でいけるはず

ぜんぜん違うじゃん

GHCの融合変換を理解する(前編) - Qiita
https://qiita.com/autotaker1984/items/5ec0bbd5a44e146dbada

なるぽよなぁ

set.iter().map(|&v| v+1).collect::<HashSet<_>>()
とか