Date: Sun, 1 Dec 2024 12:13:20 +0000
Hello there Magnus,
There was some discussion of this very idea on this mailer in January of this year. You can find the head of the thread here (https://lists.isocpp.org/std-proposals/2024/01/8910.php) - it may be worth looking over as a few ideas regarding it were raised; particularly a motivation that it could dramatically simplify the standard library spec by removing a lot of boilerplate postfix increment and decrement operators (though whether that in itself should be part of a paper to add the language feature or a later one is another matter).
For what it's worth, I'm completely on board with automatically getting postfix operators from prefix ones, and if you want any help in developing the idea I'd be very happy to work together on a paper to make it happen. I did reach out to David at the time to see how it might interact with his P1046 but it seems his interest in that paper has fizzled out, as Arthur mentioned. The tricky question is probably the precise semantics of how you get your postfix generated for you "automatically" - whether the compiler should insert a brand new implicit member function into the class, whether it should be a rewrite rule, and what mechanisms the user gets to opt-in and opt-out.
Another point for consideration is whether this approach is preferable to any of the existing approaches to affix postfix operators to classes which themselves only define postfix operators (e.g. CRTP), or indeed whether it beats out a future approach using reflection. While it's not the focus of the paper, P3294R0 - Code Injection with Token Sequences describes a case where you can create a postfix_increment() function to inject the postfix increment into a class which only defines the prefix operation. I personally believe that it is preferable to take the language feature route of automatically generating these operators rather than relying on templates/reflection for it; but if a paper were to be written then this would likely have to be explored in order to make the case that generating them from the language is a better solution.
Matthew
There was some discussion of this very idea on this mailer in January of this year. You can find the head of the thread here (https://lists.isocpp.org/std-proposals/2024/01/8910.php) - it may be worth looking over as a few ideas regarding it were raised; particularly a motivation that it could dramatically simplify the standard library spec by removing a lot of boilerplate postfix increment and decrement operators (though whether that in itself should be part of a paper to add the language feature or a later one is another matter).
For what it's worth, I'm completely on board with automatically getting postfix operators from prefix ones, and if you want any help in developing the idea I'd be very happy to work together on a paper to make it happen. I did reach out to David at the time to see how it might interact with his P1046 but it seems his interest in that paper has fizzled out, as Arthur mentioned. The tricky question is probably the precise semantics of how you get your postfix generated for you "automatically" - whether the compiler should insert a brand new implicit member function into the class, whether it should be a rewrite rule, and what mechanisms the user gets to opt-in and opt-out.
Another point for consideration is whether this approach is preferable to any of the existing approaches to affix postfix operators to classes which themselves only define postfix operators (e.g. CRTP), or indeed whether it beats out a future approach using reflection. While it's not the focus of the paper, P3294R0 - Code Injection with Token Sequences describes a case where you can create a postfix_increment() function to inject the postfix increment into a class which only defines the prefix operation. I personally believe that it is preferable to take the language feature route of automatically generating these operators rather than relying on templates/reflection for it; but if a paper were to be written then this would likely have to be explored in order to make the case that generating them from the language is a better solution.
Matthew
Received on 2024-12-01 12:13:27