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