shared / weak proxy

[SidneyCogdill]

This is more of a subtle issue: proxy supports copying, but whether the copy of the proxy is aliased to the original proxy is unknown:

auto use(proxy<Setter> p) {
    auto copy = p; // Impossible to reason locally
    p->set(10);
    copy->set(42); // Will this override 10?
}

auto f() {
    auto p1 = std::make_shared<Impl>();
    use(p1); // copying will alias
    auto p2 = pro::make_proxy<Setter>(Impl{});
    use(p2); // copying will create another distinct object
}

I'm not aware of any existing constructions in the language that has this behavior. Note how shared_ptr and raw pointers guarantee an alias:

auto use(shared_ptr<ISetter> p) {
    auto copy = p; // Guaranteed to be an alias
    p->set(10);
    copy->set(42);
}
auto use(ISetter *p) {
    auto copy = p; // Guaranteed to be an alias
    p->set(10);
    copy->set(42);
}

In fact I don't even know if any other languages has that behavior. In C#/Java copying a reference type is guaranteed to create an alias just like shared_ptr in C++ does.

---

As I've created #233. if the addition of an owner type is desirable, perhaps the picture could be more completed by introducing a separate pair of "shared"/"weak" proxy types? note how this roughly replicates smart pointers in C++:

unique_ptr -> owner proxy
T * (observer_ptr) -> reference proxy
shared_ptr -> shared proxy
weak_ptr -> weak proxy

I think the addition of shared / weak proxy types can also be done by creating a thin wrapper around the existing proxy type:

• shared proxy can be created from shared_ptr, unique_ptr, weak proxy or owner proxy (converts to / creates a shared_ptr under the hood)
• weak proxy can be created from weak_ptr, shared_ptr or shared proxy (all creates a weak_ptr under the hood)
• they can all be converted into the standard proxy type.
• shared / weak proxy does not require the facade to declare support_copy to allow copying (creating alias)
• owner proxy cannot be created from shared proxy / shared_ptr (since owner proxy models a unique_ptr-like pointer)
• reference proxy can still be created from shared proxy / shared_ptr. the difference between reference proxy and weak proxy is similar to the difference between T * and weak_ptr

but i'm not sure. i know the owner / reference proxy variants are easy to make as I've wrote a working wrapper myself. but the shared / weak proxy is different: shared_ptr <-> weak_ptr conversion rules for the type erased object, and the copying without facade's support_copy probably requires building a new facade on the fly as the shared/weak proxy type itself is instantiated, so it's more involved than just fiddling with constructor rules.

[mingxwa]

@SidneyCogdill Thank you for the feedback! It is an interesting idea to create a "weak proxy". It is feasible to implement with basic_facade_builder::add_direct_convention. For example,

#include <iostream>

#include "proxy.h"

template <pro::facade F>
struct WeakFacade;

template <pro::facade F>
struct SharedFacade;

template <pro::facade F>
using WeakProxy = pro::proxy<WeakFacade<F>>;

template <pro::facade F>
using SharedProxy = pro::proxy<SharedFacade<F>>;

namespace details {

template <class T>
std::weak_ptr<T> GetWeak(const std::shared_ptr<T>& self) noexcept { return {self}; }

template <class F, class T>
SharedProxy<F> Lock(const std::weak_ptr<T>& self) noexcept {
  auto result = self.lock();
  if (static_cast<bool>(result)) { return result; }
  return nullptr;
}

}  // namespace details

PRO_DEF_FREE_AS_MEM_DISPATCH(MemGetWeak, details::GetWeak, GetWeak);
template <class F>
PRO_DEF_FREE_AS_MEM_DISPATCH(MemLock, details::Lock<F>, Lock);

template <pro::facade F>
struct SharedFacade : pro::facade_builder
    ::support_copy<pro::constraint_level::nothrow>
    ::add_facade<F>
    ::template add_direct_convention<MemGetWeak, WeakProxy<F>() const noexcept>
    ::build {};

template <pro::facade F>
struct WeakFacade : pro::facade_builder
    ::support_copy<pro::constraint_level::nothrow>
    ::add_direct_convention<MemLock<F>, SharedProxy<F>() const noexcept>
    ::build {};

struct Formattable : pro::facade_builder
    ::support_format
    ::build {};

int main() {
  SharedProxy<Formattable> p = std::make_shared<int>(123);
  WeakProxy<Formattable> w = p.GetWeak();
  {
    SharedProxy<Formattable> locked = w.Lock();
    std::cout << std::format("locked.has_value() = {}, *locked = {}\n", locked.has_value(), *locked);  // Prints: "locked.has_value() = true, *locked = 123"
  }
  p.reset();
  {
    SharedProxy<Formattable> locked = w.Lock();
    std::cout << std::format("locked.has_value() = {}\n", locked.has_value());  // Prints: "locked.has_value() = false"
  }
}

SharedProxy<F> in the example above can only be constructed from a std::shared_ptr. However, I am not in favor of adding such mechanism to the library, because it bounds to a specific (and expensive) lifetime management model (i.e., std::shared_ptr). By design, proxy does not assume the lifetime of its contained object to ensure its performance. Therefore, I do not want to encourage people to use std::shared_ptr with proxy without thinking.