Sorry for bait header. I do understand that Rust is imperative and
let statement have side-effects.
I’m trying to understand how special
self is after encountering an issue while trying my hands on Rust.
fn try_take(&mut self, key: &str) -> Result<Self::Value, String>; fn empty_checked_for<T: Debug>(&self, val: T) -> Result<T, String>;
And now compare working code:
let val = (h.try_take("a")?, h.try_take("b")?); h.empty_checked_for(val)
against one that results in borrow errors:
See playground also.
This code refactoring seems to be innocent. But in second case Rust decides to seize mutable reference for
empty_checked_for method before computing argument. This quiet blows my mind as for the person who got taste of both C/C++ and Haskell.
Since Rust is imperative I’d expect stable order of argument calculation defined by language. And indeed
fn empty_checked_for<T>(&self, val: T) can be considered as if
self should be obtained before
But on the other hand
self looses its special meaning for compiler if I try to write
fn empty_checked_for<T>(val: T, &self) to force other arguments values (and release mutable borrows) before borrowing
Is there more Rust-idiomatic approach for similar code?