vec![Strings] seems to produce slices, not Vec of strings

help
#1

I am trying to create a vector of strings using vec!, but it appears vec! converts it into a slice.
This is the code

impl ShowErr {
    pub fn new<T> (args: &mut T) -> Result<ShowErr, String>
    where
        T: Iterator<Item = String>,
(some code deleted)

    fn empty_args() {
        let mut args: Vec<String> = vec![String::from("arg1"); 1];
	assert_eq!(Err(String::from("Not enough arguments")),
	    ShowErr::new(&mut args.iter_mut()));
    }

And I get the error

error[E0271]: type mismatch resolving `<std::slice::IterMut<'_, String> as Iterator>::Item == String`
  --> src/lib.rs:31:6
   |
9  |     pub fn new<T> (args: &mut T) -> Result<ShowErr, String>
   |            --- required by a bound in this
10 |     where
11 |         T: Iterator<Item = String>,
   |                     ------------- required by this bound in `ShowErr::new`
...
31 |         ShowErr::new(&mut args.iter_mut()));
   |         ^^^^^^^^^^^^ expected struct `String`, found `&mut _`
   |
   = note:         expected struct `String`
           found mutable reference `&mut String`

Since args is a Vec of Strings, I'd expect to be able to produce an iterator from it that would return String, but that does not seem to be what is going on here

#2

strings.iter_mut() is an iterator of &mut String.

strings.into_iter() is an iterator of String.

5 Likes
#3

Thanks. This did solve that problem. I have another one, but that will be a different post assuming I get stuck again.
I will say the error message could be clearer, which is a general comment. I have seen rustc emit errors with suggestions that just lead to a different error. But it is hard to make the error messages clear to humans when they are based on the state of a parser.

#4

I understand your pain dealing with that much more “discretion” on the part of the compiler. From prior experience I wish there was a place I could go to find the most likely reason and solution to avoiding a given error surely “I wasn’t the only one who is having this problem”.

Rust has just that resource. When presented with an error code look it up in the docs. It often includes a lucid description of the cause, and exampleS of how to fix it.

Check it out here

:))

#5

Usually, this means rhat there were multiple problems in the original code and the problem that produced the first error blocked the compiler from noticing the second. It sometimes takes several rounds with the compiler, but fixing each error as it’s presented has always gotten me to working code in the end.

1 Like
#6

I have checked the --explain option, but often find my problem is more complex and the example is simple, so that the problem is clear.
I am currently working on one where I use a peekable iterator and I have yet to find why it considers a match statement to be borrowing it, so I can't use .next() on it. I have an idea, but haven't had the time to figure out that one. If I can't, it will be my next question.
Obviously the example is straightforward and does not involve iterators, but then, the error needs to be clear for the explanation to be useful.

#7

Yes, and sometimes the real error is not on the line that the compiler indicates, but at least it points out another line (like a function definition) that is incompatible with the error line, and that other line is where the error really is. The error output is long, but useful.

#8

This topic was automatically closed after 6 days. We invite you to open a new topic if you have further questions or comments.