Frank Steffahn

The original code example from #90656 seems to be behaving similar to the code in this issue, including the change to a “higher-ranked lifetime error” in 1.63.

> > I did however add such a closure _in another file_. And sure enough if I remove that closure from that other file, this problem goes away. > >...

> Perhaps it's just a naming problem, but this reads to me as if we're a) making an unsafe assumption, b) making an assumption about the Send/Sync-ness of `T` itself....

I think the requirements between “thread-safe versions of pointers”[^1] and “thread-safe versions of `UnsafeCell`”[^1] might be sufficiently different that the two things could be discussed separately, and perhaps only unified...

> Do we have any other way to smuggle pointers between scopes that would remain valid? Probably conversion to and from `AtomicPtr` does the same.

`AtomicPtr` is an interesting thing to compare against, anyways, as it does *not* place any constraint on `T` either. Thus any `SyncConstPtr`-like type would also be more consistent with the...

@joshtriplett Can you give some more context to this? This sounds a bit like a thought I’d had, too, that supporting types `T` inside of the `AssertThreadSafe` that don’t implement...

For putting this into perspective; going as far as *spawning* a thread in the destructor of a thread-local is not necessary for unsoundness. The following simpler code too reliably reports...

Only a draft since this does not explain the lifetime parameter in the documentation and since it isn’t clear whether an alternative solution with ```rust pub struct OwningRef_, } type...

I’m revisiting this again, and have some new ideas to further reduce the number of associated types traits like `Bit`, `Unsigned`, etc… would need to have. In any case, if...