On 8/22/24 18:18, Arthur O'Dwyer via Std-Proposals wrote:
> On Thu, Aug 22, 2024 at 11:00 AM Mike Reed via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
>
> On Thu, 22 Aug 2024, 16:39 Jeremy Rifkin via Std-Proposals,
> <std-proposals_at_[hidden]
> <mailto: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 <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.

Based on this logic, why would we standardize anything at all?

The point of having something in the standard is that developers are
able to unconditionally use the feature since they have the guarantee it
is supported by any C++ compiler. Otherwise, unless you're bound to one
or two specific compilers, you have to put preprocessor checks and a
fallback code path that doesn't use the non-standard extension.

Specifically re. __COUNTER__, I think this was proposed before, and the
main problem is potential for accidental ODR violations. This proposal
doesn't seem to address this problem.