[FR] noexcept prototypes/signatures about proxy

[mingxwa]

@psiha

Thank you for the feedback! We have decided to add support for noexcept from the library side (#62). Please let us know if there is anything missing.

i.e. please support noecept signatures, e.g.:

struct Foo : pro::details::dispatch_prototype<void( int ) noexcept> {
    decltype( auto ) operator()( auto && self, int const x ) { return self.foo( x ); }
};

at least it does not compile for me with the current master (Clang 17 and latest MSVC)

Please try PRO_DEF_MEMBER_DISPATCH(foo, void(int) noexcept) with the updated implementation. Actually, adding noexcept only to the definition of a dispatch does not help much in code generation, while the function pointers are still not noexcept. With the updated implementation, proxy::invoke() and proxy::operator() will be conditionally noexcept when an overload of a dispatch is declared noexcept.

Please note that types in namespace pro::details are not intended to be directly used by other projects. The semantics of these implementation details are not documented and may change in the future.

ps. likewise - a 'bit' harder :D - support custom compiler attributes (like [[gnu::pure]])
pps. If you could also give examples/documentation on how to use the library w/o the macros and detail namespace helpers?

Although we expect the helper macros PRO_XXX to cover most cases, there might be some other useful cases require more flexible customizations. It is easy to implement a dispatch or facade from scratch (see "2.2.2 Architecting with the "proxy" in P3086R0).

PRO_DEF_MEMBER_DISPATCH(Draw, void());
PRO_DEF_FACADE(Drawable, Draw);

... is equivalent to

struct Draw {
  using overload_types = std::tuple<void()>;
  void operator()(auto& self) requires(requires{ self.Draw(); }) {
    self.Draw();
  }
};

struct Drawable { 
  using dispatch_types = std::tuple<Draw>; 
  static constexpr auto constraints = pro::relocatable_ptr_constraints; 
  using reflection_type = void; 
};

It is allowed to add custom compiler attributes to these implementations, but you may need to think twice before doing so. If you ever find writing this code is more comfortable than using the helper macros, please let us know and we will evaluate whether to add support from library side. Thank you again for the valuable feedback!

[psiha]

Thanks for the update, noexcept invoke now works :)

It is allowed to add custom compiler attributes to these implementations,

Adding the attributes to dispatch definitions/prototype declarations won't do anything, just like for noexcept: the attributes would need to be propagated to the vtable/meta pointers. Unfortunately there is no conditional/template support for compiler specific function attributes in compilers themselves - making it a good opportunity to add that also to the standardization proposal :) - until then we're stuck specifing those through the constraints traits structure.

While we're at it - I've implemented an eerily similar 'constraints traits' policy (exactly with support-level enums) approach years ago in https://github.com/psiha/functionoid/blob/master/include/boost/functionoid/policies.hpp ... were you aware of this? :)

[mingxwa]

Adding the attributes to dispatch definitions/prototype declarations won't do anything, just like for noexcept: the attributes would need to be propagated to the vtable/meta pointers.

We need to evaluate each attribute case by case. While noexcept has certain advantage in code generation, we have not observed significant difference with or without [[gnu::pure]] on gcc. If you found an attribute may improve code generation, could you provide some sample code and compiler options (including command line and compiler version)?

Unfortunately there is no conditional/template support for compiler specific function attributes in compilers themselves - making it a good opportunity to add that also to the standardization proposal :)

If the motivation is enough, I think it should be reasonable to suggest an attribute into the standard.

While we're at it - I've implemented an eerily similar 'constraints traits' policy (exactly with support-level enums) approach years ago in https://github.com/psiha/functionoid/blob/master/include/boost/functionoid/policies.hpp ... were you aware of this? :)

Interesting implementation! I did not notice the design of support_level before, but looks similar with constraint_level.