Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

He lost me somewhere at closures.

> This is the same problem as the Env example above: what’s really happening here is that the FnMut trait just wants a unique reference, but since that is not part of the type system, it requests a mutable reference.

Wait, what? The closure `|| * errors += 1` wants a unique, but NOT a mutable reference to it's environment, so that it can mutate the `errors` variable?

I guess that using `only`/`uniq` instead of `mut` would definitely be clearer and less confusing. Although I don't understand why they want to remove local immutable variables, which IMO have nothing to do with "immutability", but rather with "rebinding".



For a reference to be mutable, it has to be the only outstanding reference to an object. You can create as many immutable references as you want, because the object can't change. On the other hand, if you have the unique reference to an object, there's no particular reason you shouldn't change it.

Rust's mutability is more than rebinding, though. If you want to change a value of a field in a structure, which is something that doesn't involve rebinding the variable, you have to have a mutable variable holding the structure. The mutability is "inherited" from the variable.


The context of that is it it wants a unique reference to a mutable one, i.e. `&only (&mut int)`.


Well, it doesn't mutate the `errors` variable. `errors = &mut someothervar;` would be illegal there. It dereferences a pointer (that itself is immutable, this doesn't matter as long as it's unique) to a mutable value and mutates that value, like it says on the tin.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: