[BUG] Calling find_name() in the wrong order makes things unfindable about cursive

[gyscos]

Hi, and thanks for the report!

If the problem was just I should drop the result of find_name() before making another call, that would be fine with me provided it were documented/enforced.

We can and should indeed better document it!

The result from find_name "locks" the view you found, and prevents finding child views while this lock is kept.
(Why do we lock the view? So we can implement DerefMut, which lets users directly call methods on the result.)

This is why it's usually preferred to use call_on_name (it's harder to mix up locks this way).

I'm not sure we could enforce it though: it's valid to use find_name on disjoint views, it's only an issue when one is nested another the other one.

[c-jiph]

Thanks for getting back to me.

I'm not sure we could enforce it though: it's valid to use find_name on disjoint views, it's only an issue when one is nested another the other one.

I was imagining find_name would return some kind of guard which would mark the view as "locked". Then whenever find_name is called it would search from child to root checking to make sure everything is "unlocked", panicing if not. Once the guard is dropped the lock would be released.

Having said that, I hadn't considered call_on_name and TBH wasn't really sure why this would be used until now. Does call_on_name have the same issue if it's re-called in a nested context? If not it sounds like this is also valid way to enforce things and perhaps the find_name doc can just recommend call_on_name.

Either way some mention in the docs would be most helpful.