Tracking issue for `borrow_state` stabilization

[aturon]

The RefCell API offers a way to determine the state of the borrow, to avoid panics on additional borrowing. It's not clear how useful this API is in practice, but it's otherwise ready for stabilization.

---

EDIT: @KodrAus

Before stabilization:

• Add a concrete, motivating example to the documentation Introduce RefCell::try_borrow_unguarded #59211 (comment)

[sfackler]

I believe @nikomatsakis has mentioned that he's found a use for these methods at some point, but I can't remember what those uses were off the top of my head.

[nikomatsakis]

I've never used this pattern in Rust, but in previous lives I've been in the situation where I had a graph that was supposed to be acyclic. I was walking the graph, acquiring locks on the nodes as I went. This should not result in deadlock. The problem was that the graph was constructed from untrusted user input, and hence a deadlock was possible if the input was in error. This was neatly solved by using a 'try lock' structure, such that whenever we failed to acquire a lock, we could infer that the graph was potentially cyclic (and, if so, report an error). I can easily imagine a similar scenario arising with RefCell.

[alexcrichton]

This issue is now entering its cycle-long FCP for stabilization in 1.5

[Gankra]

I argued in the meeting today that we should instead opt to break the fallible/infallible convention and just have try_ versions of the borrow methods.

General ambivalence about this problem. This will remain unstable for at least one more release.

[alexcrichton]

The libs team discussed this during triage today and the decision was to punt to a future FCP.