Why include this in the language at all, when you could just build
something like it yourself?
You could then include whatever special corner case functionality you
wanted or roll your own UUID type functionality.
(example only: if needed add your own literalization/stringification)

//-std=c++23
constexpr int COUNT()
{
    static int i=0;
    return ++i;
}

Chris++;

On Thu, Aug 22, 2024 at 10:06 AM Jens Maurer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On 22/08/2024 17.24, Sebastian Wittmeier via Std-Proposals wrote:
> > To remove the #pragma once precedence, the __COUNTER__ proposal could
> instead also standardize #pragma once and other similar quasi-standards.
>
> What? No feature creep for this paper, please.
>
> Jens
>
> >
> > -----Ursprüngliche Nachricht-----
> > *Von:* Arthur O‘Dwyer via Std-Proposals <
> std-proposals_at_[hidden]>
> > *Gesendet:* Do 22.08.2024 17:19
> >
> > 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.
> >
> >
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>