Allow mut value, not just mut reference

[medozs]

Just a question: Is there a way in rust to cast &mut into a value, so you can use the variable directly instead of pointers?

For example:

 let a = &mut true as .....?;
 a = false;

instead of doing:

 let a = &mut true;
 *(a) = false;

I value flexibility in a language.

[gbutler]

let mut a = true;
...
a = false;

That’s what “let mut a” is saying. It is saying, “I can reassign a new value to this variable a later in this scope”.

[medozs]

What about ref keyword? It’s synonyms with & to a great degree.

[wesleywiser]

Just a question: Is there a way in rust to cast &mut into a value, so you can use the variable directly instead of pointers?

There was a rejected RFC to add a built-in API for that idiom: https://github.com/rust-lang/rfcs/pull/1736

[H2CO3]

And that’s bad enough in itself. E.g. I strongly dislike writing ref-patterns where & would do, so I prefer

let ptr = &something;

over

let ref ptr = something;

However, ref patterns are inevitable in some situations, for example when pattern matching on a reference-to-enum:

let e = &Some(move_only_value);
match *e {
    Some(ref ref_to_move_only) => …,
    None => …,
}

So, because it is basically necessary, ref was added as a pattern component, but then for completeness and generality, it was allowed to (not restricted from) being used in let bindings, which are just regular patterns anyway.

[H2CO3]

That’s not “flexibility”, that’s a plain old type error. If you have a reference, why do you want to assign a bool to it? Magic implicit conversions don’t do any good except in the most limited cases, and this is not one of them. There would be no value in this, it would merely allow some erroneous code to slip through type checking. That sharply opposes Rust’s goals and overall design philosophy.

Dereferencing a pointer literally requires one character of typing, the prefix * operator. I simply do not buy that it’s so much of a burden that it warrants removing a useful type system restriction from the language altogether.

[medozs]

Since there are special uses for the ref keyword, and usage difference between &mut and let mut, I am sure when = (mut) val is implemented, there will be special situations where it’s necessary for code to be written in this form.

[scottmcm]

What about ref keyword? It’s synonyms with & to a great degree.

Yes, and ref is so confusing and misleading that we got the match ergonomics RFC, which idiomatically kills ref. (Of course it’s still allowed for compat, but I’d pretty much teach it as “don’t use it ever”.)

[kornel]

More examples how mutability of the binding is different from mutability of the reference:

let a = &mut S{v:1};
a = &mut S{v:2}; // error

let mut b = &mut S{v:1};
b = &mut S{v:2}; // ok

let a2 = S{v:1};
a2 = S{v:2}; // error

let mut b = S{v:1};
b = S{v:2}; // ok

and

let a = S{};
let mut a = a; // ok!

let a = &S{};
let a = &mut a; // error, different meaning
let a = &mut *a; // error

[kornel]

ref/& mix-up is unfortunate, and got me quite confused when I was learning Rust.

Perhaps the patterns should have used * instead of & to mean dereference as an action rather than match of a reference:

let a = &Some(1);
match a {
  &Some(ref x) => {}
}

should have been

let a = &Some(1);
match a {
  *Some(&x) => {}
}

[medozs]

But I’m not here to create a new keyword, I’m just proposing to allow place flexibility of mut. It can come after let, and after assignment.

[skysch]

Right now, mut is allowed in patterns but not expressions. You want to add it to expressions… to do what? What does it mean there? It’s hard to imagine what that would mean in arbitrary expressions. What does let a = (mut a + b) mean, for instance?

Or do you mean to allow it only in the outermost part of expressions after a let statment?

[medozs]

For flexibility as I said, people would have the choice of the spot for mut place. Actually mut is allowed in expression but in the form of &mut. My proposal would be parallel to that.

[skysch]

&mut in an expression is quite different from mut in a pattern. &mut creates a exclusive reference, and mut allows a binding to be changed. They’re only analogous in the sense that they allow changes to happen, but it doesn’t go much farther than that. They allow totally different kinds of changes.

[hyeonu]

Basically adding syntax to the language itself is expense, not income, though it often(usually?) can be justified by being more usable/idiomatic/expresive/etc. So “more flexible” can’t be a reason to add a syntax to the language. At least, it’s not an enough basis to persuade people in this forum.

[ExpHP]

I’m just proposing to allow place flexibility of mut.

…okay. To be honest, at this point I’m still not even sure what you’re suggesting. On the one hand you’re saying that you’re “just allowing mut to appear in more places.” On the other hand, it looks like you’re trying to introduce some concept of a "mut Type" or something. (at least, that would seem to be the level of complexity needed just to make even the simplest edge cases work)

There’s no point in arguing when I don’t even understand what I’m arguing against. So please help us understand your proposal. Here’s a bunch of simple yes/no questions. Please answer them according to how your proposal is intended to work.

// 1a. Is this valid syntax?
// 1b. If so, is y mutable?
let (x, y) = (3, mut 3);

// 2. Does this compile?
let tuple = (3, mut 3);

// 3a. Does this compile?
// 3b. If so, are x and y mutable?
let (x, y) = mut (3, 3);

// 4a. Is this valid syntax?
// 4b. Is y mutable?
let f = |x| x;
let y = f(mut 2);

// 5a. Is this valid syntax?
// 5b. If so, is y mutable?
let f = |x| mut x;
let y = f(2);

// 6. Is y mutable?
let x = mut 3;
let y = x;

Edit: removed question 7.

[josh]

With this and the several other similar threads you’ve opened: What problem are you trying to solve?

Rust, as a language, is very amenable to proposals for potential language improvements. However, someone making such a proposal needs to explain the problem they’re trying to solve, and why the existing language doesn’t solve the problem (or doesn’t do so effectively enough).

In doing so, such a proposal should also demonstrate a clear understanding of how the language already works, at least in the area in question, in order to motivate a change to how it works.

Many syntax proposals, for instance, get pushback of the form “you could do this with a macro”, and it’s up to the proposer to explain why that doesn’t suffice.

In the case of this and several other proposals you’ve made recently, there seems to be an underlying theme of some kind of frustration you’re having, perhaps between the Rust language and the way you’re trying to use it, along with (intentional) differences in behavior between Rust and other programming languages. That’s fairly normal, especially when learning the language. However, rather than making an array of proposals for how Rust could behave differently, you might consider seeking some help with the difficulties you’re encountering with Rust and with potential solutions or mental models that might make your path easier. For instance, you might try Rust’s friendly IRC channels.

[medozs]

I don’t have any problems, I am just suggesting proposals that could lead rust better and easier as well as being more wide spread in programming world. I would like people to use rust for example instead of go. That’s what I’m trying to achieve.

[notriddle]

There has been a similar request a couple of days ago, whereby someone proposed the alternative var spelling instead of let mut.

Not “somebody”.

@medozs I’m not sure why you expected people to like this proposal when they didn’t like var. But, really, it has the same problem; it doesn’t fit with the way Rust’s pattern-matching system works, and it doesn’t seem to improve things. It doesn’t even make the code shorter! At least var had that going for it.

I am just suggesting proposals that would lead rust better and easier as well as being more wide spread in programming world.

Do you have any evidence that micro-scale syntax flexibility actually does make programming languages more successful? Because I think the widespread success of Python is evidence that it’s not required.

[medozs]

No, there aren’t any new types. It’s just equivalent to let mut a = value but with mut is moved to expression. The behavior stays the same.

// 1a. Is this valid syntax? // 1b. If so, is y mutable? let (x, y) = (3, mut 3);

a. Yes, b. Yes

// 2. Does this compile? let tuple = (3, mut 3);

A. Yes

// 3a. Does this compile? // 3b. If so, are x and y mutable? let (x, y) = mut (3, 3);

a. Yes, b. Yes

// 4a. Is this valid syntax? // 4b. Is y mutable? let f = |x| x; let y = f(mut 2);

a. No, b. No

// 5a. Is this valid syntax? // 5b. If so, is y mutable? let f = |x| mut x; let y = f(2);

a. No, b. No

// 6. Is y mutable? let x = mut 3; let y = x;

A. No