Whole-known-network
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> okay. and you would expect this would give actual benefit over using one of the regular Cells and hoping the compiler can figure it out?</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> if you can guarantee you never create two &mut pointers to the same thing (note: creating is as bad as accessing) you can just use unsafe code to do so (UnsafeCell probably)</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> I assume that the costs of both Cell and RefCell can be removed by the compiler if those "borrowed" stretches are sufficiently short, but I don't know which one of the two is more likely to get removed correctly and efficiently.</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> and I guess when threads are not in operation the idea is that the "given out" thing is long lived and you request the same thing a second time?</p><p>Assume the relevant field is not pub and is accessed in a limited number of places, and I can eyeball all "give outs" (I'd say "borrows" here but I'm not sure it's the right word) and be entirely certain they don't overlap. Assume also this is a code "hot path". What would you do in this situation?</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> (actually you can get a &mut pointer to the inside of an Rc with a refcount of exactly 1 but this does not help you)</p><p>earlier post in other words: concurrency can happen even within a single thread of execution</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> you can't get a &mut pointer to the inside of an Rc, which is why if you want one, you have to add a second thing that gives it out</p><p>this second thing has to avoid giving it out twice while itself being a &Thing which is Copy</p>
<p>I have a theory what the answer to this is going to be, but I want to hear somebody say it.</p>
<p>Okay. Here is a question. Would you (reading this) agree that Rc<RefCell<>> is redundant, and in this case Rc<Cell<>> makes more sense? Since Rc<> is !Send, it seems to me that the additional protections in RefCell<> are wildly unnecessary and protecting against a case that cannot happen, since only one thread could possibly access the variable at a time. But Cell only works with Copy types, so apparently the Rust language design folks disagree.</p>
<p>I did not make it the entire day. I made it until 4:30 and then wound up writing a fairly involved Rust patch. This wasn't an intentional choice. It just sort of happened; I made a decision and I thought I was just documenting the decision I'd made.</p><p><a href="https://github.com/mcclure/lisp0-experiment/commit/c14977bb8244800325997873a281a7f14dad3419" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://</span><span class="ellipsis">github.com/mcclure/lisp0-exper</span><span class="invisible">iment/commit/c14977bb8244800325997873a281a7f14dad3419</span></a></p><p>This is bad, because it required me to think about Arc, Rc, RefCell, and the relationships therebetween, which (as always) caused me mental anguish and made my headache worse, the thing I was trying to avoid on my day off</p>