I think it's Rust's type system that tricks some people into thinking it's a functional language. But it's just not, really it's not.
@jimblandy functional impls are ALWAYS allowed to do global mut as long as it can prove nobody cares. Rust gives those tools to everyone.
-
-
@jimblandy consider fn foo(self, val: u32) -> T { self.x = val; self } ; functional style with mutation as impl detail -
@wycats Sure, we can call that functional. But everyone writes f(&mut self, ...) which is not. x.f() can return a different value each time? -
@jimblandy what problems of in-place mutation is functional style trying to address? -
@wycats Functional code makes the flow of information more explicit, and it's true that x.f() can only mutate things named in that call. -
@wycats But by threading state arguments into and out of functions, we can turn any single-threaded imperative code into functional code. -
@wycats So I feel if we accept x.f() mutating x as equiv to passing x and then receiving a new x on the way out, we've given up too much. -
@jimblandy in order to make state threading work universally, we have to make the fields of the data structure public, which is costly too.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.