New useful macro to std , mut!

[tomerze]

Recently I came across this amazing crate on crates.io.

Simple useful and reads well.

I suggest making it part of the standard library.

But to avoid confusion with other languages change the macro to mut!.
Example:

mut! { 
    a = 5,
    b = 3,
    c = “hello”
}

Is much more readable than
let (mut a, mut b, mut c) = (5, 3, ”hello”);

[Lonami]

How about let mut (a, b, c) = (5, 3, "hello");?

[RustyYato]

I don't think that this ahould be added because Rust wants you to avoid mutation where possible, and this would be counter to that goal.

Similarly with

let mut (a, b, c) = (5, 3, "hello");

[tomerze]

@KrishnaSannasi
I know.
I think making the user use a macro and open a whole block with "{ }" is expensive enough. You are not going to use it if you can just use "let" because using "let" is still easier.

It still makes you think "Do I really need this to be mutable?" , while making the code more readable.

[RustyYato]

Yes, but let's say you already have a mut! { ... } block, it would be easier to just add a new variable to the block than to define a let new_var = val; so it encourages mutability when editing. Also in the vast majority of code, you shouldn't need more than a handful of mutable variables in a function so it's not a big enough papercut to justify the macro.

[Centril]

How about let mut (a, b, c) = (5, 3, "hello");?

This was decided against in #2401.

[tomerze]

@KrishnaSannasi
Same thing can be said for "let". let's say you already got a "let" it would be easier to add another var to the "let" rather than use the "mut!" macro.

It's just that the "mut!" macro is a little bit harder to write and to look at (it's a whole block). That's the syntax salt here. if needed you can even go as far as to purposely make the name of the macro longer.

It's not about making the user write bad code to get a mutable variable it's about making it a little bit less convenient and letting the user know he is using the language in a way it wasn't designed to be used and the whole macro thing gets the point across.

[RustyYato]

Same thing can be said for "let". let's say you already got a "let" it would be easier to add another var to the "let" rather than use the "mut!" macro.
yes, but with let it is easier to change this

let (mut x, mut y) = ...;

to

let (mut x, mut y, z) = ...;

Than to

let (mut x, mut y, mut z) = ...;

So Rust still favors immutability.

It's not about making the user write bad code to get a mutable variable it's about making it a little bit less convenient and letting the user know he is using the language in a way it wasn't designed to be used and the whole macro thing gets the point across.

Rust doesn't want to make it easier to make mutable variables, so making it more convenient isn't that great. Also, adding mut var_name isn't that hard, so I don't see the point in adding a whole new macro to the std.

Same thing can be said for "let". let's say you already got a "let" it would be easier to add another var to the "let" rather than use the "mut!" macro.

Disclaimer This section is mostly my personal taste and opinion, and reflects my habits when programming.

No, it would be about the same to add it to either, it may even be easier to add it to the mut! macro if it was formatted like this,

mut! {
    var_name = val,
    foo = val,
    bar = val,
}

Now you just need to go to a line in the macro, press enter and viola you can make a new variable. Compare that to adding it to a let binding, you have to go to the end of the tuple pattern (which can be a little tedious as getting right before the paren is annoying), then you can add a new binding. Or you can do let variable = value; which is more typing than adding to the mut! block.

The cost of the mut block is also amortized over how many variables you have in there, the more variables, the less bad it looks.

Finally, a mut! block encourages grouping all of your variables in one place, which makes reasoning about the lifetime of the variables more difficult than if they were limited to just where they are used. Doubly so when they are mutable.

[Centril]

The keyword mut is well... a keyword. This means that this proposal is not implementable under our current constraints that a keyword should remain one. Closing therefore.

[RustyYato]

@Centril I don't think that is a big issue, we could follow suit with the library and name it var instead. That said, I don't think that we should implement this even if it was renamed to var.

[tomerze]

@Centril it's not about how you call it it's about the idea itself. I acknowledge that calling it "mut" was a bad idea impossible to implement. Something like "mutables" should do. "var" can be confusing with other languages (we don't want people to write Rust like it's JavaScript). But practically how you call it doesn't matter it's a useful macro to have.

[RustyYato]

@TomerZeitune This is basically the same as var from JavaScript, which is why I am so against it. If you introduce this into the std, regardless of the name, people will just use it like var.

[Pauan]

As a meta note, Rust really prefers to keep things in third-party crates as much as possible.

Rust tries hard to not move things into the stdlib unless there's a very compelling reason to do so.

Third-party crates are great: they can be independently versioned, they can have breaking changes, they can do crazy experiments that cannot be done in the stdlib, etc.

If something goes into the stdlib, it's there forever, and it can never change. That has caused a lot of problems with other languages (e.g. Python), which is why Rust is so against it.

[tomerze]

@KrishnaSannasi
I'm not a JavaScript guy but I am pretty sure mutable let is the same as "var" from JavaScript.

It's not that it's fundamentally wrong to use it it's just that it shouldn't be the default for a variable.

I don't think this macro can or will make mutable variables the go to default in Rust for various reasons I described above.

I think the name can also suggest how you should use it. So by having "mut" somewhere in the name we automatically make it very clear that you should use it for when you need mutable variables. Not for every variable like the name "var" suggests .

I personally use this lib and it's really a much more subtle change than you might think.