If there was a mechanism to reset the counter, like
#pragma counter set 0
People could use that in order to make the behavior deterministic.


To be fair I have never used __COUNTER__ and I don't I see myself ever using it, because it is not at all all that useful, or predictable.

There's nothing wrong with standardizing existing practice. The fact that it is so widespread is a good argument as to why it should be standard. If we rely on it, it is good to write it down as part of the de facto standard.

But the problem of just standardizing current practice is that sometimes there might be a better solution, and we might miss out on a much better "could have been" because we were to focus on "what it is right now".

The standardization process is long and takes time, thinking about alternative solutions and implementations is a good thing, even if what ends up happening is what we already know.
We don't just want a solution, we want the best solution, one that is helpful for years to come.


________________________________
From: Jeremy Rifkin <rifkin.jer_at_[hidden]>
Sent: Friday, August 23, 2024 3:08:54 AM
To: std-proposals_at_[hidden] <std-proposals_at_lists.isocpp.org>
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] __COUNTER__

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]m>
> 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]rg> 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_lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals