I don't think a mechanism to control the counter value would be
entirely sufficient for addressing this
problem. Or at the very least it might lead to libraries that aren't
as ergonomic as they could be. I'm
not sure a counter push/pop would be either.

I kind of like the idea of multiple counters, maybe something like this?

int x = __COUNTER__; // 0
int y = __COUNTER__(a); // 0
int z = __COUNTER__(a); // 1
int z = __COUNTER__; // 1

I'm wary of scope-creeping this paper, I have intended to write a very
focused existing practices proposal.
However, the ODR problem is worth solving. The duality of __COUNTER__
as a normal macro an object-like
macro and a function-like macro makes wording a little more challenging.

Jeremy


On Thu, Aug 22, 2024 at 8:57 AM Tiago Freire via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> That could be solved if you could reset the counter to some value. Or better yet the ability to have more than one counter.
> Or perhaps one could dream of a pre-processor language, after all incrementing a counter is just a small subset of things you would want to do with a macro.
> ________________________________
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Thursday, August 22, 2024 5:35:59 PM
> To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> Cc: Andrey Semashev <andrey.semashev_at_[hidden]>
> Subject: Re: [std-proposals] __COUNTER__
>
> On 8/22/24 18:22, René Ferdinand Rivera Morell via Std-Proposals wrote:
> > On Thu, Aug 22, 2024 at 10:00 AM Mike Reed via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> >>
> >> 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.
> >
> > Given that.. It would be more useful to standardize some form of
> > __UUID__ that matches the current __COUNTER__ use cases.
>
> I think, it would make ODR issues even worse than __COUNTER__. Imagine
> __UUID__ used in a header included in multiple TUs.
>
> You could argue for some sort of hash over __FILE__ and byte offset in
> the current file combined, where __FILE__ is a canonical path.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals