libc++ is using

#define _LIBCPP_AUTO_CAST(expr) static_cast<typename decay<decltype((expr))>::type>(expr)

which has equivalent-ish semantics and inferior throughput. I suspect they would like to replace that with auto(expr) when possible.

On Tue, Jan 4, 2022 at 11:47 AM Jonathan Wakely via SG10 <> wrote:

On Tue, 4 Jan 2022 at 19:27, Barry Revzin via SG10 <> 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 <>
Date: Tue, Jan 4, 2022 at 1:25 PM
Subject: Fwd: New issue: auto(x) should have a feature-testing macro
To: Barry Revzin <>
Cc: Zhihao Yuan <>, <>

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 <>
Reply-To: Zhihao Yuan <>
To: William M. \(Mike\) Miller <>
CC: 'Arthur O'Dwyer' <>

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
SG10 mailing list