On Tue, 4 Jan 2022 at 19:27, Barry Revzin via SG10 <sg10@lists.isocpp.org> wrote:
Do you have an example of code that would benefit from such detection?

And what is the alternative code that you'd use in the #else branch?

If the alternative has equivalent semantics and performance, we don't need a macro.


---------- Forwarded message ---------
From: William M. (Mike) Miller <wmm@edg.com>
Date: Tue, Jan 4, 2022 at 1:25 PM
Subject: Fwd: New issue: auto(x) should have a feature-testing macro
To: Barry Revzin <barry.revzin@gmail.com>
Cc: Zhihao Yuan <zy@miator.net>, <arthur.j.odwyer@gmail.com>

This suggestion should be decided by SG10 rather than being
handled as a core language issue, so I'm forwarding it to the
SG10 chair for consideration. Thanks.

-------- Forwarded Message --------
Subject: New issue: auto(x) should have a feature-testing macro
Date: Tue, 14 Dec 2021 02:48:12 +0000
From: Zhihao Yuan <zy@miator.net>
Reply-To: Zhihao Yuan <zy@miator.net>
To: William M. \(Mike\) Miller <wmm@edg.com>
CC: 'Arthur O'Dwyer' <arthur.j.odwyer@gmail.com>

It's hard to detect whether it is legal to
do auto(expr) after adopting P0849R8;
A feature testing macro would help.

There was no __cpp_auto (unlike
__cpp_decltype_auto), but the direction
of evolving auto(x) is probably not
necessarily tied to `auto` in a

Proposed resolution:

This wording is relative to N4901.

Add an entry to [tab:cpp.predefined.ft]

Table 21: Feature-test macros

| Macro name  | Value |
| -------- | ------- || <ins>__cpp_auto_cast</ins> | 202110L |

Zhihao Yuan, ID lichray

The best way to predict the future is to invent it.

SG10 mailing list