Hi Bengt,

In general, I like the idea of @decorator, but there are several implications that needs to be considered:

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

> the same as the Python counterpart.

Not really. In Python @decorator def func means to literally pass the returned value from func to the decorator function. In potential-future-P0707, @decorator func means to pass the entire token sequence of the body of func to the decorator function. Therefore I don’t think the analogy actually makes sense.

> 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.

How is @decorator some_entity different from just decorator(some_entity)? AFAIK the semantics of the former is just to pass some_entity to the decorator…

> 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.

In fact, there are. @keyword is used in Objective-C[++] specifically because that avoid clashes with C++ keywords, so things like @interface cannot work. Also, there exists a proposal (P3254) that proposes to use @something as annotation tokens instead of [[=something]] currently proposed.

Just my 2c.

Best regards,

Yihe Li

From: SG7 <sg7-bounces@lists.isocpp.org> on behalf of Bengt Gustafsson via SG7 <sg7@lists.isocpp.org>
Date: Tuesday, 22 October 2024 at 05:18
To: sg7@lists.isocpp.org <sg7@lists.isocpp.org>
Cc: Bengt Gustafsson <bengt.gustafsson@beamways.com>
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 <herb.sutter@gmail.com>
To:	'Bengt Gustafsson' <bengt.gustafsson@beamways.com>

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 <bengt.gustafsson@beamways.com>

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

> To: Herb Sutter <herb.sutter@gmail.com>

> 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