On Thu, Aug 22, 2024 at 11:00 AM Mike Reed via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, 22 Aug 2024, 16:39 Jeremy Rifkin via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> Hello,
>> I've drafted a proposal to standardize __COUNTER__:
>> https://jeremy-rifkin.github.io/cpp-proposals/drafts/counter_initial_draft.html
>> .
>>
>
> Given that nearly every use case is to produce a unique identifier,
surely the last thing you want overflow to do is silently wrap to zero. I
would expect the standard to mandate that overflow forces a compile error.

+1 re overflow.

I'm ambivalent on the proposal. It is obviously standardizing useful
existing practice. *But* the very ubiquity of __COUNTER__ means that its
standardization won't help anyone.
One way to (politically) motivate an existing-practice proposal is to go
find some implementation divergence, and claim that your proposal would
resolve that divergence, thus improving the user's life. But if there is no
divergence — or if your proposal fails to resolve what divergence exists —
then you haven't got a case.
An example of this scenario is `#pragma once`. Literally every vendor
supports `#pragma once`; but it's never been standardized, because the cost
of standardization is high and the benefit would be literally zero: *nobody*
is prevented from using `#pragma once` just because it's non-standard.
The cost of standardizing `__COUNTER__` is much lower (because the spec is
very simple), but the benefit is still literally zero.

IMO your new bullet point should go before `__DATE__`, not before
`__cplusplus`.
You might want to specify that the expansion is a *decimal* integer literal.
Probably you shouldn't refer to "the value of __COUNTER__," but rather
introduce a new thing e.g. "the counter" which can have a value, and then
use the name __COUNTER__ only for the macro, which *expands* to an integer
literal but doesn't *have a value* per se. But it doesn't make sense to
spend *too* much time on that wordsmithing right now.

HTH,
–Arthur