4 ms·
When I wrote my comment, I was actually looking at how variables inside a method are declared, not fields (attributes, as they call it in this language) like yo
by knocte 12y ago
When I wrote my comment, I was actually looking at how variables inside a method are declared, not fields (attributes, as they call it in this language) like you mention (seems like the 'variable' keyword is not for local variables, but for attributes).
So I was mainly hoping it is like F#, that forces you to decorate non-immutable variables with the `mutable` keyword, inside a method/function.
However, thinking about it more deeply, this is not so important. Because local variables (in a method) are never shared between threads. So immutability doesn't suffer from them being mutable. Right?
- twic 12y agoProbably right. One of the Rust developers suggested something similar (but more nuanced, because Rust is a highly nuantial language): http://smallcultfollowing.com/babysteps/blog/2014/05/13/focusing-on-ownership/ http://smallcultfollowing.com/babysteps/blog/2014/05/13/focu... "Put another way, it’s become clear to me over time that the problems with data races and memory safety arise when you have both aliasing and mutability. The functional approach to solving this problem is to remove mutability. Rust’s approach would be to remove aliasing." Local variables themselves are naturally non-aliased, although the objects they point to might be. PS apologies to anyone who's seen it before for trotting that link out yet again!
- gavinking 12y agoIn Ceylon even local variables must be explicitly annotated `variable`. The reason for that is that a local variable could be captured by an anonymous function or nested function, and escape from the local scope, so it's exactly the same situation with a local variable as for an instance variable of a class: both kinds of variable break referential transparency.