Are you proposing that `m.add(1,2)` should be just syntactic sugar for
`print_logs([]m.add, 1, 2)`, where []x.y is N3617
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3617.htm>'s and
P0834
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0834r0.html>'s
(quite nice, but never yet adopted-by-C++) syntactic sugar for
`[&](auto&&... args){return m.add(decltype(args)(args)...);}` ? Or is it
syntactic sugar for something else? Or is `m.add` itself now really some
other kind of entity? or what?
If you are proposing exactly the P0834-style approach, then what happens
with something like `(++p)->add(1, 2)`?
Also, how would this (whatever it is) interact with forward-declarations?...
  int f(); // foo.h
  @decorated int f() { return 42; } // foo.cpp

Also, your item (1) mentions inheritance, but I don't see evidence that
you've thought about what your feature should do in the presence of
inheritance, e.g.
    struct Base { virtual int f(); @decorated virtual int g(); }; // is
this OK?
    struct Derived : Base {
      @decorated int f() override; // is this OK?
      int g() override; // what about this?
    };
    Derived d;
    d.g(); // does this call go via the decorator, or not?

Meanwhile, you should probably be aware that in the current year (2024)
Brian Bi attempted with P3254
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3254r0.html> to
clear the way for treating `_at_xyz` as a single token — but EWG didn't care
for that (at least not at the moment, without any further feature work to
build on it). My impression, though, is that he was trying to sell @xyz as
a possible future replacement for [[xyz]] (i.e. attributes), rather than as
a totally new thing (decorators). So this is a point against your syntax,
but only a very minor point IMHO.
https://github.com/cplusplus/papers/issues/1914

–Arthur


On Sat, Oct 26, 2024 at 1:25 PM zys via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Dear all:
> When I want to execute additional code before functions without changing
> the source code, there are several approaches I can take:
>
> 1. Use C++ inheritance and override the original function.
> 2. Use function hooks at the compile time.
> 3. Use lambda functions, etc.
>
> In Python, decorators can assist developers in achieving this and are
> widely used. Therefore, it is suggested that C++ also adds decorators as a
> syntactic sugar to help developers quickly implement the execution of extra
> code before and after functions.
> for examples：
> #include <stdio.h>
> #include <iostream>
>
> template <class Func, class... Args>
> auto print_logs(Func &&func, Args &&...args)
> {
> printf("this is a log\n");
> return func(std::forward<Args>(args)...);
> }
>
> @print_logs // Execute print_logs before executing add.
> int add(int a, int b)
> {
> return a + b;
> }
> int common()
> {
> add(1, 2); // print "this is a log\n"
> // Replace the add above with the following code at pre-compilation.
> // print_logs(add, 1, 2);
> return 0;
> }
>
> struct math
> {
> @print_logs
> int add(int a, int b) { return a + b; }
> };
> int instead_of_lamda()
> {
> math m;
> m.add(1, 2); // print "this is a log\n"
> // Replace the add above with the following code at pre-compilation.
> // print_logs([&](int a, int b)
> // { return m.add(a, b); }, 1, 2);
> return 0;
> }
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>