Thanks for the thoughts,
I see only a few obvious cases on github code search of defining
__COUNTER__ in user code:
https://github.com/search?type=code&q=%2F%23%5Cs*define%5Cs*__COUNTER__%2F+-is%3Afork
many of which are defining it to fall back to __LINE__, e.g.:
#ifndef __COUNTER__
#define __COUNTER__ __LINE__
#endif
I am happy to go either way on the feature detect macro. I initially
wrote it down in the interest of thoroughness, thinking it couldn't
hurt, but I can see the argument that it may be unnecessary. Should
this be removed from the proposal before it is sent to the committee?
> Is overflow anything that happens in reality, ever?
Not that I know of, but I will ask some folks I know who spend more
time stress testing the preprocessor than I. I agree that __COUNTER__
overflow should basically never happen and if it did it would be the
least of your problems.

Jeremy

On Mon, Aug 26, 2024 at 6:33 AM Tiago Freire via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> I'm with Jens on this one.
> If you are in the position where it could overflow, how it overflows would be the least of your problems.
>
> -----Original Message-----
> From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Jens Maurer via Std-Proposals
> Sent: Monday, August 26, 2024 12:53 PM
> To: std-proposals_at_[hidden]
> Cc: Jens Maurer <jens.maurer_at_[hidden]>
> Subject: Re: [std-proposals] Second draft of a __COUNTER__ proposal
>
>
>
> On 26/08/2024 12.38, Andrey Semashev via Std-Proposals wrote:
> > On 8/26/24 12:11, Jens Maurer wrote:
> >>
> >>
> >> On 26/08/2024 10.44, Andrey Semashev via Std-Proposals wrote:
> >>> On 8/26/24 11:43, Andrey Semashev wrote:
> >>>> On 8/26/24 09:33, Christof Meerwald via Std-Proposals wrote:
> >>>>>
> >>>>> Does this really need a separate feature test macro when you can
> >>>>> just test on __COUNTER__ itself?
> >>>>
> >>>> __COUNTER__ may be defined by user.
> >>
> >> No. See [lex.name] p3.1
> >
> > Reserved or not, a user is not prevented from using the name. A
> > compiler that does not support __COUNTER__ will not prevent the user
> > from defining the macro.
>
> Well, you get undefined behavior if you do use __anything today, unless it's a name specified by the standard. I don't think we should bend over backwards for such code.
>
> >>> ...or have non-standard semantics.
> >>
> >> Improbable, given the implementation experience we've seen here.
> >
> > Current compilers don't implement errors on overflow, so already not
> > conforming to the proposal.
>
> My understanding is that current implementations have at least a 2^31 counter space, meaning you need 2^31 expansions of __COUNTER__ to hit the limit. That feels quite a lot, considering we're talking tokens in source code here.
>
> Is overflow anything that happens in reality, ever?
>
> >> I'm in favor of not having a feature-test macro.
> >
> > If __COUNTER__ is standardized then I'm in favor of a feature macro.
>
> We obviously disagree here.
>
> Jens
>
>
> --
> 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