3 ms·
> That's the thing, & really has nothing to do with constness or immutability No, that means 'reference', but the `mut` and lack of work mean exclusive mutabil
by jnordwick 7y ago
> That's the thing, & really has nothing to do with constness or immutability
No, that means 'reference', but the `mut` and lack of work mean exclusive mutability and const respectively. So another term that means share mutability makes sense.
> And the language has quite simply moved in the opposite direction to that of having more shorthand syntax
Most definitely not. Recent examples are `?` and `async` that replace types with syntax. And coming up the pipe is going to be most coroutines are probably going to get their own syntax too. While year ago that might have been the case (and I think Box should have retained its sigil), the more recent trend is back in the other direction.
Also, not that we already have `mut` and `` (no marker), mixing forms would be bad at this time, we instead of `shm` or something we get cells that correspond to the `mut` for shared mutability.
And regardless of the syntax question, it is still a massive end around the borrow checker and people refuse to admit how hacky it is.
- zozbot234 7y ago> No, that means 'reference', but the `mut` and lack of work mean exclusive mutability and const respectively. You keep saying this, but it's just not the most straightforward way of understanding the language - no matter what the official docs say at this time. It might be fair to complain about the lack of true 'const', 'pure' etc. specifiers in Rust, but to say that & references are 'const' references is just not sensible IMHO. It might make more sense to make a similar claim about C++, where the 'mutable' keyword really does seem to be a hack like you describe. But C++ has no borrow checker in the first place hence no such motive for 'interior' mutability - so it's in a totally different situation.