owner / reference variant of proxy

[SidneyCogdill]

proxy is specifically designed such that it erases ownership (and custom allocator) information. both std::make_unique<Impl>() and Impl * can be converted into a proxy<Interface> and its resource lifetime will be managed correctly.

This is powerful but not always intended. for example when I'm certain that my interface only wants to "observe" a state, under traditional sense it's a well established convention to use a std::unique_ptr<State> for owner, and pass the raw pointer obtained from .get() express that it's only passing a non-owning view to that interface. ref: C++ Core Guidelines

With proxy I don't think there is a way to distinguish owner from non-owning observer. Consider this example:

void f2(proxy<Setter> p)
{
    p->set(42); // #2
}

auto f(proxy<SetterGetter> p)
{
    f2(&*p); // #1
    poly_vec().push_back(std::move(p)); // #3
}

SetterGetter can upcast into Setter. The interface f needs to set something on the object before storing it inside a vector. Passing a non-owning reference to a proxy polymorphic object can be done with & + * operators. The problem is when f2 also accepts a proxy<F>, this defeats local reasoning. the definition of f2 may be invisible and only a declaration is visible (void f2(proxy<Setter>)). With solely a function signature it's impossible to reason the intent of f2. It might want to take the ownership of the object (std::move), or it might want to perform mutating operations (mutable reference). The implementer of f2 is in a similar state: will the lifetime of p end as soon as the scope ends? can it be captured inside a coroutine promise and be used later? A proxy<Setter> tells nothing about it.

It would be ideal if another two types of proxy are introduced that models owner and reference:

• both owner and reference can be converted into the standard proxy type.
• owner variant can only be initialized or assigned with smart pointers, or with the owner variant of pro::make_proxy.
• reference variant can only be assigned with raw pointers, or another instance of owner / standard proxy type. reference variant is different from the standard proxy in the sense that its destructor is guaranteed to be trivial (doesn't do anything).

This will not lose the benefits of proxy library, but allows those who want to better reason object lifetime to be able to explicitly state the ownership property. further more the owner / reference model aligns closely with the [[gsl::Owner]] / [[gsl::Pointer]] attributes available in various toolchains, which means that static analyzers can now reason with proxy's lifetime.

It shouldn't be hard to implement either, as it can be implemented by:

• first introducing them using only a thin wrapper around the existing proxy type with slightly different constructors.
• adding a owner variant of pro::make_proxy and friends which doesn't accept raw pointers or another instance of owner/proxy, something like make_unique_proxy or make_owning_proxy.

I would expect using them like this:

auto &poly_vec()
{
    static std::vector<proxy<SetterGetter>> v;
    return v;
}

void f2(reference<Setter> p)
{
    p->set(42);
}

auto f(owning<SetterGetter> p)
{
    f2(p);
    poly_vec().push_back(std::move(p));
}

[SidneyCogdill]

it seems like proxy_view models the "reference" variant very closely: #218 (didn't notice this as it hasn't landed in release version yet). Although why does add_view add metadata to the vtable? I thought the &* operation in my example would just type-erase the accessor.

And it still lacks an explicit owner proxy type (only constructable from unique_ptr or make_unique_proxy), which will be useful when reasoning with "can I put this object into coroutine and expect it to not explode"

[mingxwa]

@SidneyCogdill Thank you for the feedback! I have published the 3.2.0 release that contains proxy_view and basic_facade_builder::add_view you mentioned above. Please check out the spec.

Although why does add_view add metadata to the vtable?

Because it converts a (potentially "fancy") pointer into a raw pointer, like std::unique_ptr::get() does. proxy_view offers better performance when invoked or passed to another function (it's trivially copyable) than &*p. Passing &*p to a function is also acceptable (the type is proxy_indirect_accessor, also introduced in 3.2). It's user's choice to balance between speed and binary size.

And it still lacks an explicit owner proxy type

This looks more like the responsibility of coding guidelines. Using raw pointers could always "explode" in C++, and users should be aware of this.

[SidneyCogdill]

I have published the 3.2.0 release

Nice! I've updated conan recipe to 3.2.0: conan-io/conan-center-index#26454

This looks more like the responsibility of coding guidelines.

Coding guidelines could work. I feel like having the requirements enforced by C++ type system is less error-prone though. Meanwhile I'll just use this wrapper in my own codebase:

template<typename First, typename... Rest>
struct first_type
{
    using type = First;
};
template<typename... Ts>
using first_type_t = typename first_type<Ts...>::type;

template<pro::facade F>
struct owning : proxy<F>
{
    template<typename T>
    owning(T &&p)
        requires(!std::is_pointer_v<std::remove_cv_t<T>>
                 && !std::is_same_v<proxy<F>, std::remove_cvref_t<T>>)
                && requires { proxy<F>(static_cast<decltype(p)>(p)); }
        : proxy<F>(static_cast<decltype(p)>(p))
    {}

    template<typename... Args>
    static owning<F> make_unique_proxy(Args &&...args)
        requires(!(sizeof...(Args) == 1
                   && (std::is_pointer_v<std::remove_cvref_t<first_type_t<Args...>>>
                       || std::is_same_v<proxy<F>, std::remove_cvref_t<first_type_t<Args...>>>) ))
    {
        return owning<F>(pro::make_proxy<F>(static_cast<decltype(args)>(args)...),
                         UnsafeRawPointerMarker{});
    }

private:
    struct UnsafeRawPointerMarker
    {};

    template<typename T>
    explicit owning(T &&p, UnsafeRawPointerMarker)
        requires(std::is_pointer_v<std::remove_cv_t<T>>)
                && requires { proxy<F>(static_cast<decltype(p)>(p)); }
        : proxy<F>(static_cast<decltype(p)>(p))
    {}

    owning(proxy<F> &&p, UnsafeRawPointerMarker)
        : proxy<F>(std::move(p))
    {}
};

It's not bullet-proof but it should prevent common pitfalls.

[mingxwa]

Although I am not convinced the benefit of owning is more than the complexity it introduced (does std::shared_ptr count for "owning"? what about boost::interprocess::offset_ptr?), you can simply author a "reflector" type and use basic_facade_builder::add_direct_reflection to prevent a proxy from being constructed from a raw pointer. For example:

#include "proxy.h"

struct FancyPointerOnlyReflector {
  template <class P>
  constexpr explicit FancyPointerOnlyReflector(std::in_place_type_t<P>)
      requires(!std::is_pointer_v<P>) {}
};

struct MyFacade : pro::facade_builder
    ::add_direct_reflection<FancyPointerOnlyReflector>
    ::build {};

int main() {
  static_assert(!pro::proxiable<int*, MyFacade>);
  static_assert(pro::proxiable<std::unique_ptr<int>, MyFacade>);
}

[SidneyCogdill]

Thanks. the reflector example is exactly what I needed.

Although the owning will be useful when Lifetime TS is properly implemented: https://wg21.link/p3465r0 since you can slap a [[gsl::Owner]] on owning (I don't think you can put attributes to only parts of proxy<F> when you don't control the partial specialization)

[mingxwa]

The [[gsl::Owner]] is a good point that I have not thought before. I guess maybe the following code could work if [[gsl::Owner]] can propagate from a base type to a derived type (this is how accessibility is implemented in Proxy).

struct FancyPointerOnlyReflector {
  template <class P>
  constexpr explicit FancyPointerOnlyReflector(std::in_place_type_t<P>)
      requires(!std::is_pointer_v<P>) {}

  [[gsl::Owner]]
  template <class F, bool IsDirect, class R>
  struct accessor {};  // proxy<F> will instantiate and inherit accessor<F, true, FancyPointerOnlyReflector>
};

I will learn more about the recent safety proposals and explore any potential overlaps with Proxy. BTW, thank you for updating Proxy in conan!