Tracking issue for `downgraded_weak` (No way to construct std::rc::Weak without a strong reference)

[shahn]

When deserializing Weak, there's currently no clean way to handle the case that there's no strong reference anymore. Serializing doesn't have the same issue. There seem to be two solutions to this, either provide an explicit constructor that returns a Weak without using a strong reference to create it, or implementing Default for it that does the same. I prefer the former, as Default might be a bit surprising.

This would be a simple, non-backwards-incompatible change. Possible constructor name bikeshedding: Weak::new_downgraded()

Unstable APIs

• Weak::new

[Aatch]

/cc @rust-lang/libs

[sfackler]

I feel like I'm missing a bit of context here - wouldn't the stored object immediately be freed since the strong reference count will be zero?

[huonw]

@sfackler, yeah, the Weak<T> never actually contains a T so it's always non-upgradable, but it allows deserialising things that happen to contain a Weak (where it isn't unexpected for the Weak to be invalid).

[Gankra]

Seems easy enough to add. Basically Option::None.

[oli-obk]

Weak could simply implement Default...

[shahn]

@oli-obk It could, but wouldn't it be a bit surprising that the Default for Weak is an unusable Weak?

[sfackler]

Ah, got it. Weak::new_empty() (or whatever name) seems reasonable enough.

[Gankra]

Just to be clear: an empty Weak would still allocate memory. We're all in agreement that this is the desired semantic? The alternative would be adding a sentinel state to every weak pointer that needs to be checked on every access.

[Veedrac]

If you care about allocating memory for empty Weaks, you could make them point to some thread-local instead. Just increment the thread-local's weak count on construction and make sure it starts with a count of 1 so it never gets deallocated.

It sounds like a needless optimization for a rare case, and the aliasing is probably undefined behaviour without care, but it's workable if you really want it.

[shahn]

Yes, it's fine to allocate the memory (you even want to do it to match the pre-serialization state). Having a constructor called new_* should make that clear, imo

[apasel422]

This was implemented in #30467.

[shahn]

I think this issue needs to stay open until a stabilization decision was made