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