Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tuple's are not allowed as lvalues #10174

Closed
adrientetar opened this issue Oct 30, 2013 · 8 comments
Closed

Tuple's are not allowed as lvalues #10174

adrientetar opened this issue Oct 30, 2013 · 8 comments

Comments

@adrientetar
Copy link
Contributor

Currently, this is unimplemented:

fn main() {
    let (x,y) = (1,2);
    (x,y) = (3,4);
}

The line (x,y) = (3,4); will trigger an error.

This is allowed in Python for example and can come in handy:

def fib_increment(n):
  a,b = 0,1
  for _ in range(n):
    a,b = b,a+b
  return a

Here, b allocated value depends on a and vice-versa. Not sure how this translates into lower-level code but at least here it spares an alloc and a line of code.

Also, being able to allocate a tuple from a function would come in handy, cf. #7507#issuecomment-23618416.

See #7507, #7508, #10123.

@emberian
Copy link
Member

cc @nikomatsakis

@emberian
Copy link
Member

I was under the impression we weren't allowing this for grammar reasons.

@eddyb
Copy link
Member

eddyb commented Dec 16, 2013

We can translate Expr to Pat, or even handle a tuple of values specially in trans, do we need anything a pattern can express that an expression can't?
ref and mut affect the resulting binding (so they don't make sense in destructuring assignment).
&x in Expr creates an rvalue, so there would be no ambiguity in the language (though it might be confusing for users) as to it being a dereference in a destructuring assignment.

@Aatch
Copy link
Contributor

Aatch commented Mar 23, 2014

If anybody is still interested in this, an official RFC should be filed. https://github.com/rust-lang/rfcs/blob/master/active/0001-rfc-process.md

@Aatch Aatch closed this as completed Mar 23, 2014
@adrientetar
Copy link
Contributor Author

@Aatch Are you closing all issues tagged as B-RFC?

@Aatch
Copy link
Contributor

Aatch commented Mar 23, 2014

@adrientetar not all, just a few that clearly should go through the new RFC process, I only did 7.

@adrientetar
Copy link
Contributor Author

@Aatch Well this is a feature request and not a proposed implementation so it is not going to go any further.

@huonw
Copy link
Member

huonw commented Mar 23, 2014

RFCs are not (just) for proposed implementations but rather extensions to the language, which is exactly what this is.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 12, 2023
hotfix: remove `ITER_COUNT` since it is not called

`&paths:ITER_COUNT` is not being called from anywhere, so removing it doesn't seem to be a problem.

---

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants