4 ms·

I know what it is. I've been involved with Rust on and off for about 4 years (now more off than on, but periodically stepping back in). IM has always seemed li

I know what it is. I've been involved with Rust on and off for about 4 years (now more off than on, but periodically stepping back in). IM has always seemed like a really bad wart - an intentional breaking of the borrow checking through idiom rather than a language construct. Just as `&` is an shared const ref, `&mut` is an exclusive mutable ref, but for some reason when you get to shared mutable instead of making `multimut&` or something, the language invokes cells then has the audacity to straight-face proclaim you can share mutable references. I guess if they made `multimut&` ref they would have to admit is is possible I guess. The difference between the syntactic and cell-based representation of that type of share mutable reference always seemed like no real difference. I do a lot of C++ and having to basically do hygienic macros though template metaprogramming is on the same level. I'd rather just have hygienic macros. Cells are the Rust equivalent of removing const through template without ever having to cast it away explicitly. An intentional breaking of const through idiom rather than syntax. If tomorrow a shorthand cell was introduced like `shm&` (similar to how `?` was introduced as shorthand for dealing with Result types), it would bring it into the realm of syntax and be much clearer what was going on. Cell seems like a straight up step around the borrow checker for shared mutability. It should look like the other references.

zozbot234 7y ago
That's the thing, & really has nothing to do with constness or immutability, and a consistent description of the language should make that clear. It's not a language problem, it's a documentation problem. And the language has quite simply moved in the opposite direction to that of having more shorthand syntax. Box<> and the then-equivalent of Rc<> used to have their own shorthand sigils in Rust, but these were replaced with writing out the type constructors. Again, if it's reasonably consistent, there's nothing wrong with that. It's quite different from the '?' syntax which is replacing what used to be a special macro, 'try!'. Macros can do almost anything with the code and are pretty hackish, type constructors not really.
- 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.

zozbot234 7y ago

That's the thing, & really has nothing to do with constness or immutability, and a consistent description of the language should make that clear. It's not a language problem, it's a documentation problem. And the language has quite simply moved in the opposite direction to that of having more shorthand syntax. Box<> and the then-equivalent of Rc<> used to have their own shorthand sigils in Rust, but these were replaced with writing out the type constructors. Again, if it's reasonably consistent, there's nothing wrong with that. It's quite different from the '?' syntax which is replacing what used to be a special macro, 'try!'. Macros can do almost anything with the code and are pretty hackish, type constructors not really.

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.