Closed
Description
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.
Activity
emberian commentedon Nov 16, 2013
cc @nikomatsakis
emberian commentedon Nov 16, 2013
I was under the impression we weren't allowing this for grammar reasons.
eddyb commentedon Dec 16, 2013
We can translate
Expr
toPat
, or even handle a tuple of values specially in trans, do we need anything a pattern can express that an expression can't?ref
andmut
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 commentedon 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
adrientetar commentedon Mar 23, 2014
@Aatch Are you closing all issues tagged as
B-RFC
?Aatch commentedon Mar 23, 2014
@adrientetar not all, just a few that clearly should go through the new RFC process, I only did 7.
adrientetar commentedon Mar 23, 2014
@Aatch Well this is a feature request and not a proposed implementation so it is not going to go any further.
huonw commentedon Mar 23, 2014
RFCs are not (just) for proposed implementations but rather extensions to the language, which is exactly what this is.
Auto merge of rust-lang#10174 - chansuke:hotfix/remove-paths, r=dswij