Yeah, I would like a placeholder name proposal. A way to introduce an entity that can't be referred to, but otherwise behaves identically to a named entity of the same kind. It would be useful for structured bindings, lock guards, macros. It also doesn't share the ODR-violation footgun with __COUNTER__ .
On 16 August 2022 16:51:05 BST, Marcin Jaczewski via Std-Proposals <firstname.lastname@example.org> wrote:
wt., 16 sie 2022 o 17:02 Arthur O'Dwyer via Std-Proposals
On Tue, Aug 16, 2022 at 10:26 AM Lénárd Szolnoki via Std-Proposals <email@example.com> wrote:
On 16 August 2022 12:53:00 BST, Frederick Virchanza Gotham via Std-Proposals <firstname.lastname@example.org> wrote:
Every C++ compiler suite I'm aware of supports the preprocessor macro __COUNTER__.
It is an ODR-violation footgun when used in header files.
I think `__COUNTER__` can be useful; but it's just like `#pragma once` — every vendor already supports it, a fair bit of code depends on it, so what's the point of all the bickering to add it to the Standard? It's easier to just maintain the status quo, which is that it's non-standard but it works.
But there could be divergences between vendors that could affect
implementation, besides I recall the only case where it could be
useful is for creating variable with unique name.
If it is only real use of it could it be better solved by the compiler?
int i##__COUNTER__ = foo(); //not valid code but idea is clear?
int _ = foo(); // or `?` or any other symbol for bikeshedding
or something like this.
For comparison, C++ once tried to standardize the equally widespread vendor practice of
#define CALL(...) call(1, 2, 3 ,##__VA_ARGS__)
to mean "eliminate the trailing comma if __VA_ARGS__ is empty," and after they got through with it we ended up with a whole new thing called __VA_OPT__, and the original code remains a non-standard extension.
Std-Proposals mailing list