Thanks Bengt,

 

Yes, the syntax in current P0707 is mainly just to be following what SG7 last directed. Example:

 

               // Current P0707, per SG7’s last direction

     class(interface) IFoo { … };

 

But now that we have @, I agree with Bengt that

 

               @interface class IFoo { … };

 

is both

 

a) cleaner (fun fact: it’s exactly my original P0707R0 proposed syntax and C++/CLI syntax, adding only the @ which I agree makes a big difference for parsing and legibility), and

 

b) more generalizable in the future to functions (as Bengt mentions), and this is definitely intended… two canonical examples are

 

               @pure int f(int a, int b) { … }

* example of a consteval function that could reflect on the body of f to enforce that the return value depends only on the parameters

 

               @autodiff double f(double d) { … }

* example of a consteval function that could additionally generate the first derivative of f as f_prime (or d_f or whatever)

 

The function metafunctions are also useful, not yet proposed in P0707, but which I intend to work on in cppfront this winter. I have a potential volunteer to try to prototype the latter example (autodiff) in C++ which has long been something that would have been useful for programmers in the ML and AI spaces

 

Herb

 

 

From: SG7 <sg7-bounces_at_[hidden]> On Behalf Of Bengt Gustafsson via SG7
Sent: Monday, October 21, 2024 2:19 PM
To: sg7_at_[hidden]
Cc: Bengt Gustafsson <bengt.gustafsson_at_[hidden]>
Subject: [isocpp-sg7] Fwd: P0707

 

Hi all,

I suggested to Herb that P0707 should use the decorator syntax from Python instead of the inheritance syntax from Python. I think this would cause less confusion as the semantics seems to be exactly the same as Python decorators, modulo the consteval part of it of course. This decorator syntax could then be applied in various places where you may want to modify something before actually adding it to the program.

Our conversation is below.

Bengt


-------- Forwarded Message --------


Subject:

RE: P0707


Date:

Sat, 19 Oct 2024 16:10:05 -0700


From:

Herb Sutter <mailto:herb.sutter_at_[hidden]> <herb.sutter_at_[hidden]>


To:

'Bengt Gustafsson' <mailto:bengt.gustafsson_at_[hidden]> <bengt.gustafsson_at_[hidden]>






Hi Bengt,

 

The reason I'm currently using class(decorator) is only because that's what SG7 last recommended.

 

I like that, and it did cross my mind when we added @. It's similar to what I use in Cpp2:

               MyClass: @decorator type = { }

 

I probably should mention it -- I'll add it to rNext of the paper. Thanks!

 

Herb

 

P.S.: Would you like to repeat your feedback to the SG7 reflector? I think it's a great suggestion.

 

 

 

> -----Original Message-----

> From: Bengt Gustafsson <mailto:bengt.gustafsson_at_[hidden]> <bengt.gustafsson_at_[hidden]>

> Sent: Saturday, October 19, 2024 2:08 PM

> To: Herb Sutter <mailto:herb.sutter_at_[hidden]> <herb.sutter_at_[hidden]>

> Subject: P0707

>

> Hi Herb,

>

> why not adopt the

>

> @decorator class MyClass {};

>

> syntax from Python?

>

> We just added the @ character and as far as I can see the semantics is exactly

> the same as the Python counterpart.

>

> This opens up for allowing decorators on functions and in the future maybe

> other constructs with the same (rather well-known) syntax. Or maybe even a

> blanket allowance: Wherever you can put ^^ before a contruct you can put

> @function-name instead and let the consteval function adjust the contents of

> the following entity.

>

> As long as we haven't used @ for something else there should be no parsing

> issues. I can imagine that someone wants @ to be an identifier character but I

> haven't seen a proposal for this.

>

> Bengt

>

>

> --

> Bengt Gustafsson