I'd like to destructure a tuple and assign part of the result to a new variable and assign another part of the result to an existing.
The following code illustrates the intent (it's a dumb example which results in an infinite loop printing [0]):
fn main() {
let mut list = &[0, 1, 2, 3][..];
while !list.is_empty() {
let (head, list) = list.split_at(1);
// An obvious workaround here is to introduce a new variable in the above
// let statement, and then just assign it to list.
println!("{:?}", head);
}
}
This code creates a new variable list instead of reassigning it.
If I change the code to the following (to avoid the let that introduces the new list variable), it doesn't compile:
fn main() {
let mut list = &[0, 1, 2, 3][..];
while !list.is_empty() {
let head;
(head, list) = list.split_at(1);
println!("{:?}", head);
}
}
Compilation error:
error[E0070]: invalid left-hand side of assignment
--> src/main.rs:5:22
|
5 | (head, list) = list.split_at(1);
| ------------ ^
| |
| cannot assign to this expression
|
Is there a way to do this, or can destructuring only be used in let, match, and for statements?
No.
Destructuring is something you can only do with patterns; the left-hand side of an assignment is not a pattern, hence you can't destructure-and-assign.
See proto-RFC 372 (Destructuring assignment) which discusses the possibility of adding this feature.
Yes.
The Rust team has published a new version of Rust 1.59.0 in Feb. 24, 2022, you can now use tuple, slice, and struct patterns as the left-hand side of an assignment.
Announcing Rust 1.59.0
Destructuring assignments
You can now use tuple, slice, and struct patterns as the left-hand side of an assignment.
let (a, b, c, d, e);
(a, b) = (1, 2); [c, .., d, _] = [1, 2, 3, 4, 5]; Struct { e, .. } =
Struct { e: 5, f: 3 };
assert_eq!([1, 2, 1, 4, 5], [a, b, c, d, e]);
This makes assignment more consistent with let bindings, which have
long supported the same thing. Note that destructuring assignments
with operators such as += are not allowed.
Before 1.59.0, you can only destructure it in Nightly version with #![feature(destructuring_assignment)].
Now you can do this trick in stable version and remove the feature line.
See more details from rust-lang/rust/issues/71126 and rust-lang/rust/pull/90521.
Nightly Rust has feature(destructuring_assignment), which allows your original attempt to compile as-is:
#![feature(destructuring_assignment)]
fn main() {
let mut list = &[0, 1, 2, 3][..];
while !list.is_empty() {
let head;
(head, list) = list.split_at(1);
println!("{:?}", head);
}
}
[0]
[1]
[2]
[3]
However, I'd solve this using stable features like slice pattern matching, which avoids the need for the double check in split_at and is_empty:
fn main() {
let mut list = &[0, 1, 2, 3][..];
while let [head, rest # ..] = list {
println!("{:?}", head);
list = rest;
}
}
See also:
How to swap two variables?
Related
In my understanding, s[0..] calls the method ops::Index::index. I try to call s.index(0..), but find that it returns a type of &str. The code is as follows
let a = String::from("hello world");
let b = &a;
let c = b.index(1..);
println!("{}", c);
let d = b[1..];
println!("{}", d);
This code will display an error, and indicate that the variable d is of type str.
What do I understand wrong? and how to understand the [] and index() in rust?
In the documentation of std::ops::Index, we find:
container[index] is actually syntactic sugar for *container.index(index)
and
This allows nice things such as let value = v[index] if the type of value implements Copy.
In your example, c has type &str as you expect, but d would be the dereference (*) of such an &str; this would lead to str which is rejected by the compiler (not sized).
In order to obtain a &str in d, you could write:
let d = &b[1..]; // & was missing
which is really explicit because it clearly states: «I want to refer to something which stands inside b».
Here is another example of the implicit dereference (*) in a different context:
let mut arr = [1, 2, 3, 4];
let n = arr[1]; // not *arr[1]
arr[2] += n; // not *arr[2]
println!("{:?}", arr); // [1, 2, 5, 4]
I have a vector of numbers and use the windows(2) method to create an iterator that gives me neighbouring pairs. For example, the vector [1, 2, 3] is transformed into [1, 2], [2, 3]. I want to use the find method to find a slice that fulfills a specific condition:
fn step(g: u64) -> Option<(u64, u64)> {
let prime_list: Vec<u64> = vec![2, 3, 5, 7]; //For example
if prime_list.len() < 2 {
return None;
}
let res = prime_list.windows(2).find(|&&[a, b]| b - a == g)?;
//...
None
}
I get an error:
error[E0005]: refutable pattern in function argument: `&&[]` not covered
--> src/lib.rs:6:43
|
6 | let res = prime_list.windows(2).find(|&&[a, b]| b - a == g)?;
| ^^^^^^^^ pattern `&&[]` not covered
I don't know what that error means: the list cannot have less than two elements, for example. Maybe the closure parameter is wrong? I tried to vary it but that didn't change anything. a and b are being properly detected as u64 in my IDE too. What is going on here?
You, the programmer, know that each iterated value will have a length of 2, but how do you know that? You can only tell that from the prose documentation of the function:
Returns an iterator over all contiguous windows of length size. The windows overlap. If the slice is shorter than size, the iterator returns no values.
Nowhere does the compiler know this information. The implementation of Windows only states that the iterated value will be a slice:
impl<'a, T> Iterator for Windows<'a, T> {
type Item = &'a [T];
}
I'd convert the slice into an array reference, discarding any slices that were the wrong length (which you know cannot happen):
use std::convert::TryFrom;
fn step(g: u64) -> Option<(u64, u64)> {
let prime_list: Vec<u64> = vec![2, 3, 5, 7]; // For example
if prime_list.len() < 2 {
return None;
}
let res = prime_list
.windows(2)
.flat_map(<&[u64; 2]>::try_from)
.find(|&&[a, b]| b - a == g)?;
//...
None
}
See also:
How to convert a slice into an array reference?
How can I find a subsequence in a &[u8] slice?
How do I imply the type of the value when there are no type parameters or ascriptions?
Alternatively, you could use an iterator of integers and chunk it up.
See also:
Are there equivalents to slice::chunks/windows for iterators to loop over pairs, triplets etc?
At some point in the future, const generics might be stabilized and allow baking the array length into the function call and the return type.
See also:
Is it possible to control the size of an array using the type parameter of a generic?
I have two HashSet<u16>s and I would like to implement a = a U b. If possible, I'd like to use HashSet::union rather than loops or other tweaks.
I tried the following:
use std::collections::HashSet;
let mut a: HashSet<u16> = [1, 2, 3].iter().cloned().collect();
let b: HashSet<u16> = [7, 8, 9].iter().cloned().collect();
// I can build a union object that contains &u16
let union: HashSet<&u16> = a.union(&b).collect();
// But I can't store the union into a
a = a.union(&b).collect(); // -> compile error
// of course I can do
for x in &b {
a.insert(*x);
}
// but I wonder if union could not be used to simply build a union
The error message is the following:
the trait bound
`std::collections::HashSet<u16>: std::iter::FromIterator<&u16>`
is not satisfied
How can I perform a = a U b?
You don't want union — as you said, it will create a new HashSet. Instead you can use Extend::extend:
use std::collections::HashSet;
fn main() {
let mut a: HashSet<u16> = [1, 2, 3].iter().copied().collect();
let b: HashSet<u16> = [1, 3, 7, 8, 9].iter().copied().collect();
a.extend(&b);
println!("{:?}", a); // {8, 3, 2, 1, 7, 9}
}
(Playground)
Extend::extend is also implemented for other collections, e.g. Vec. The result for Vec will differ because Vec does not honor duplicates in the same way a Set does.
// But I can't store the union into a
a = a.union(&b).collect(); // -> compile error
The error message is the following:
the trait bound `std::collections::HashSet<u16>:
std::iter::FromIterator<&u16>` is not satisfied
It's because a is a HashSet<u16>, but a.union(&b) is an Iterator<Item=&u16>. Converting a.union(&b) to Iterator<Item=u16> by using .copied() works:
a = a.union(&b).copied().collect(); // compiles
As the other mentioned, this will create a new HashSet. In some cases, this might be what you want, but it will make more sense if it's assigned to another variable:
let c: HashSet<u16> = a.union(&b).copied().collect();
// a is unchanged here
For collecting multiple hashsets:
use std::collections::HashSet;
fn main() {
let a: HashSet<u16> = [1, 2, 3].iter().copied().collect();
let b: HashSet<u16> = [1, 3, 7, 8, 9].iter().copied().collect();
let all = [a,b];
let combined = all.iter().flatten().collect::<HashSet<_>>();
println!("{:?}", combined);
}
Playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=44cd73eb3a4e628378cbb7ff11a32649
I have an input vector which contains numbers. In an output vector, I need to get a sequence of partial products but in right-to-left order. The last element of the output must be equal to the last one in the input; the second-to-last element of the output must be a product of the last and second-to-last elements of input; and so on. For example, if the input vector is
let input = vec![2, 3, 4];
then I need the output to be [24, 12, 4].
My implementation takes an iterator over the input, reverses it, maps, reverses again and collects:
fn main() {
let input = vec![2, 3, 4];
let mut prod = 1;
let p: Vec<usize> = input
.iter()
.rev()
.map(|v| {
prod *= v;
prod
}).rev()
.collect();
println!("{:?}", p);
}
The result is [2, 6, 24], the same as if I delete both rev()s. The two rev()s do not solve the problem, they just "annihilate" each other.
Is this task solvable in "chain of calls" style, without using for?
This behavior is actually explicitly described in the documentation:
Notes about side effects
The map iterator implements DoubleEndedIterator, meaning that
you can also map backwards:
[…]
But if your closure has state, iterating backwards may act in a way you do
not expect. […]
A way to solve this would be by adding an intermediary collect to be sure that the second rev does not apply on the Map:
fn main() {
let input = vec![2, 3, 4];
let mut prod = 1;
let p: Vec<usize> = input
.iter()
.map(|v| {
prod *= v;
prod
}).rev()
.collect::<Vec<_>>()
.into_iter()
.rev()
.collect();
println!("{:?}", p);
}
But that requires an extra allocation. Another way would be to collect, and then reverse:
fn main() {
let input = vec![2, 3, 4];
let mut prod = 1;
let mut p: Vec<usize> = input
.iter()
.rev()
.map(|v| {
prod *= v;
prod
}).collect();
p.reverse();
println!("{:?}", p);
}
Your prod variable is carrying state across from one item to the next, which is not what a mapping does. Mappings operate on each element independently, which makes them easily parallelized and easier to reason about. The result you're asking for is to be precise a right scan (a reversed case of a prefix sum), but I'm not sure there are convenient methods to collect from the right (probably the easiest mutable way would be using VecDeque::push_front). This led me to perform the operation in two passes for my first version:
fn main() {
let input: Vec<usize> = vec![2, 3, 4];
let initprod = 1;
let prev: Vec<usize> = input
.iter()
.rev()
.scan(initprod, |prod, &v| {
*prod *= v;
Some(*prod)
}).collect();
let p: Vec<usize> = prev.into_iter().rev().collect();
println!("{:?}", p);
}
Note that initprod is immutable; prod carries the state. Using into_iter also means prev is consumed. We could use vec.reverse as shown by mcarton, but then we need to have a mutable variable. Scans can be parallelized, but to a lesser degree than maps. See e.g. discussion on adding them to Rayon. One might also consider if a ExactSizeIterator should allow reverse collection into an ordinary vector, but the standard library scan method breaks the known size using Option (which by the next convention turns it into a take-while-scan).
Here's a fewer copy variant using a preallocated VecDeque to collect from the right. I used an extra scope to restrict the mutability. It also requires Rust 1.21 or later to use for_each. There's unnecessary overhead in tracking the number of items and ring buffer structure, but it's at least somewhat legible still.
use std::collections::VecDeque;
fn main() {
let input: Vec<usize> = vec![2,3,4];
let p = {
let mut pmut = VecDeque::with_capacity(input.len());
let initprod = 1;
input
.iter()
.rev()
.scan(initprod, |prod, &v| {
*prod *= v;
Some(*prod)
})
.for_each(|v| {
pmut.push_front(v)
});
pmut
};
println!("{:?}", p);
}
Incidentally, following the old adage about Lisp programmers knowing the value of everything and the cost of nothing, here's a Haskell version I don't really know how inefficient it is:
scanr1 (*) [2, 3, 4]
Can someone explain why this compiles:
fn main() {
let a = vec![1, 2, 3];
println!("{:?}", a[4]);
}
When running it, I got:
thread '' panicked at 'index out of bounds: the len is 3 but the index is 4', ../src/libcollections/vec.rs:1132
If you would like to access elements of the Vec with index checking, you can use the Vec as a slice and then use its get method. For example, consider the following code.
fn main() {
let a = vec![1, 2, 3];
println!("{:?}", a.get(2));
println!("{:?}", a.get(4));
}
This outputs:
Some(3)
None
In order to understand the issue, you have to think about it in terms of what the compiler sees.
Typically, a compiler never reasons about the value of an expression, only about its type. Thus:
a is of type Vec<i32>
4 is of an unknown integral type
Vec<i32> implements subscripting, so a[4] type checks
Having a compiler reasoning about values is not unknown, and there are various ways to get it.
you can allow evaluation of some expression at compile-time (C++ constexpr for example)
you can encode value into types (C++ non-type template parameters, using Peano's numbers)
you can use dependent typing which bridges the gap between types and values
Rust does not support any of these at this point in time, and while there has been interest for the former two it will certainly not be done before 1.0.
Thus, the values are checked at runtime, and the implementation of Vec correctly bails out (here failing).
Note that the following is a compile time error:
fn main() {
let a = [1, 2, 3];
println!("{:?}", a[4]);
}
error: this operation will panic at runtime
--> src/main.rs:3:22
|
3 | println!("{:?}", a[4]);
| ^^^^ index out of bounds: the length is 3 but the index is 4
|
= note: `#[deny(unconditional_panic)]` on by default
This works because without the vec!, the type is [i32; 3], which does actually carry length information.
With the vec!, it's now of type Vec<i32>, which no longer carries length information. Its length is only known at runtime.
Maybe what you mean is :
fn main() {
let a = vec![1, 2, 3];
println!("{:?}", a[4]);
}
This returns an Option so it will return Some or None. Compare this to:
fn main() {
let a = vec![1, 2, 3];
println!("{:?}", &a[4]);
}
This accesses by reference so it directly accesses the address and causes the panic in your program.