How about template attributes?

In given example, it would be something like

#include <functional>

[[nodiscard]] bool foo(int i) { return i % 2 ; }

template <class F, class... Args>
[[nodiscard<F>]]
constexpr std::invoke_result_t<F, Args...> logInvoke(F&& f, Args&&... args)
{
// Do some extra work, log the call
// ...
// Fwd call
return std::invoke(std::forward<F>(f), std::forward<Args>(args)...);
}

int main() {
foo(0); // Warning on discarded return
logInvoke(foo, 0); // No warning on discarded return
}

And now templated logInvoke would use the same [[nodiscard]] as declared by
F type.


On Mon, Apr 15, 2024 at 2:02 PM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi Aurelien,
>
> perhaps a small reference to the effect of attributes is suitable, as this
> proposal slightly changes the potential effects of attributes.
>
> If generic code reacts to whether certain attributes are present, then
> attributes can have a direct effect on what a program does.
>
> It is perhaps acceptable, as it is the program (+libraries) itself looking
> at its own (+libraries') attributes, but it is a slight shift from
> "attributes can just be ignored".
>
> Currently the standards committees can make sure, how attributes are used.
>
> With reflection, it is in the hands of the users.
>
> This will open up a lot of uses, but also misuses.
>
>
>
> Best,
>
> Sebastian
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Aurelien Cassagnes via Std-Proposals <
> std-proposals_at_[hidden]>
> *Gesendet:* So 14.04.2024 03:33
> *Betreff:* [std-proposals] Attributes introspection
> *An:* std-proposals_at_[hidden];
> *CC:* Aurelien Cassagnes <aurelien.cassagnes_at_[hidden]>;
> Draft for "Attributes introspection"
>
> Attributes are used to great extent and there likely will be attributes
> added as the language evolve.
> What is missing now is a way for generic code to look into the attributes
> related to an entity.
> A motivating example is following
>
> #include <functional>
>
> [[nodiscard]] bool foo(int i) { return i % 2 ; }
>
> template <classF,class...Args>
> constexpr std::invoke_result_t<F,Args...> logInvoke(F&& f, Args&&...
> args) {
> // Do some extra work, log the call
> // ...
> // Fwd call
> return std::invoke(std::forward<F>(f), std::forward<Args>(args)...);
> }
>
> int main() {
> foo(0); // Warning on discarded return
> logInvoke(foo, 0); // No warning on discarded return
> }
>
> Other examples of wrapping around callables can be found, whether by
> closure or explicity registering callbacks for dispatch, etc.
> The proposal here is to introduce a `declattr` keyword to look into
> attributes bound to an entity, the form would be likely equivalent to how
> `decltype` or `declval` are used.
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>