I don't see way to put a button inside of the closure

[dancespiele]

I cannot see way to resolve this error that refer to this line https://github.com/dancespiele/okspiel/blob/master/src/connect/connect_node.rs#L384 . Compile throw this:

cannot infer an appropriate lifetime for borrow expression due to conflicting requirements
   --> src/connect/connect_node.rs:384:61
    |
384 | ...                   Button::new(&mut self.copy, Text::new("Copy"))
    |                                   ^^^^^^^^^^^^^^
    |
note: first, the lifetime cannot outlive the lifetime `'_` as defined on the body at 382:91...
   --> src/connect/connect_node.rs:382:91
    |
382 | ...                   addresses.iter_mut().fold(Row::new().padding(20), |r, a| {
    |                                                                         ^^^^^^
note: ...so that closure can access `self`
   --> src/connect/connect_node.rs:384:61
    |
384 | ...                   Button::new(&mut self.copy, Text::new("Copy"))
    |                                   ^^^^^^^^^^^^^^
note: but, the lifetime must be valid for the anonymous lifetime #1 defined on the method body at 208:5...
   --> src/connect/connect_node.rs:208:5
    |
208 |     pub fn view(&mut self) -> Element<Message> {
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...so that the expression is assignable
   --> src/connect/connect_node.rs:209:9
    |
209 | /         Container::new(
210 | |             Row::new()
211 | |                 .height(Length::Fill)
212 | |                 .padding(20)
...   |
400 | |         )
401 | |         .into()
    | |_______________^
    = note: expected `iced_native::element::Element<'_, _, _>`
               found `iced_native::element::Element<'_, _, _>`

error: aborting due to previous error
```rust

[Kaiden42]

It seems you are trying to create n buttons with just one button state (self.copy). Each button needs it's own state.

[dancespiele]

@Kaiden42 maybe could be one issue but doesn't resolve the problem: https://github.com/dancespiele/okspiel/blob/master/src/connect/connect_node.rs#L394 the changes that I did are here = https://github.com/dancespiele/okspiel/commit/ce9dd396eb01e73c9fd9148a03e8c1842660082c

error[E0495]: cannot infer an appropriate lifetime for lifetime parameter in function call due to conflicting requirements
   --> src/connect/connect_node.rs:394:62
    |
394 | ...                   &mut self.copy_states[i],
    |                            ^^^^^^^^^^^^^^^^^^^
    |
note: first, the lifetime cannot outlive the lifetime `'_` as defined on the body at 390:45...
   --> src/connect/connect_node.rs:390:45
    |
390 | ...                   |r, address| {
    |                       ^^^^^^^^^^^^
note: ...so that closure can access `self`
   --> src/connect/connect_node.rs:394:62
    |
394 | ...                   &mut self.copy_states[i],
    |                            ^^^^^^^^^^^^^^^^
note: but, the lifetime must be valid for the anonymous lifetime #1 defined on the method body at 214:5...
   --> src/connect/connect_node.rs:214:5
    |
214 |     pub fn view(&mut self) -> Element<Message> {
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...so that the expression is assignable
   --> src/connect/connect_node.rs:215:9
    |
215 | /         Container::new(
216 | |             Row::new()
217 | |                 .height(Length::Fill)
218 | |                 .padding(20)
...   |
413 | |         )
414 | |         .into()
    | |_______________^
    = note: expected `iced_native::element::Element<'_, _, _>`
               found `iced_native::element::Element<'_, _, _>`

[Kaiden42]

Yes, because indexing the states doesn't solve the problem of having the possibility to have two mutable references to the same state. If you have a number a (self.copy_states[a]) in an iteration and later a number b (self.copy_states[b]), who gurantees that a is never equal to b? Instead, you have to iterate over the states.

You could either zip the state's iterator with the addresses' iterator or store the states along with the addresses in a tuple or struct like explained in #712

[dancespiele]

In the end I resolved splitting it in different views. You can see more here .