Should weak be a type?

[Nickolas_Pohilets (Nickolas Pokhylets)]

@John_McCall

You're confusing implementation details with semantics here quite a bit, but I think I can puzzle it out: you'd like to be able to create references to an object which don't keep it alive but do stay "valid" in the sense of never being confusable with a reference to any other object even after the object is destroyed. Those references would never be "resurrectable"; they'd just be usable as stable keys in dictionaries and so on. It turns out that we actually have most of the facilities we'd need for this already as part of the implementation of unowned references. How would you expect to use these?

I’m working on an in-house reactive programming framework. Framework heavily relies on comparing inputs to decide if something should be recomputed or update propagation can stop.

And data that users feed into the framework may contain pretty much anything including weak references and closures. To facilitate framework usage we ship a collection of property wrappers that help compiler synthesize equality conformance for user types.

False positives in equality lead to bugs - if I were using ObjectIdentifier as a comparison key, there is a small chance that old object (some sort of delegate) would be destroyed, new one would be created at the same address, but framework would never propagate a reference to the new one.

False negatives lead to redundant updates - negativity affecting performance, but preserving correct behavior.

I think for most of the user use cases weak references don’t outlive the referent, up to some unaccounted dispatch_async. So typically weak is used instead of unowned as a defensive measure.