Date: Thu, 22 Aug 2024 13:46:18 -0400
The point of `__COUNTER__` is to generate unique identifiers in
preprocessor expanded code. constexpr functions can't alter the lexing
phase like the preprocessor can.
Also, I wasn't aware that a core constant expression could refer to a
non-`constexpr` variable with static storage duration.
On Thu, 22 Aug 2024 at 13:35, Chris Ryan via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
preprocessor expanded code. constexpr functions can't alter the lexing
phase like the preprocessor can.
Also, I wasn't aware that a core constant expression could refer to a
non-`constexpr` variable with static storage duration.
On Thu, 22 Aug 2024 at 13:35, Chris Ryan via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-08-22 17:46:32