> A consteval could very much help with a custom identifier

How could this help with a use case such as google benchmark's use of
__COUNTER__, which boils down to essentially:

#define CONCAT_IMPL(x, y) x##y
#define CONCAT(x, y) CONCAT_IMPL(x, y)
#define NEW_VAR(name) CONCAT(name, __COUNTER__)
#define BENCHMARK(fn) [[maybe_unused]] auto NEW_VAR(_benchmark_) =
(::benchmark::internal::RegisterBenchmarkInternal(#fn, fn));

Expanding to, e.g.:

[[maybe_unused]] auto _benchmark_6 =
(::benchmark::internal::RegisterBenchmarkInternal("bench_fn",
bench_fn));

Jeremy

On Mon, Aug 26, 2024 at 1:41 PM Robin Savonen Söderholm
<robinsavonensoderholm_at_[hidden]> wrote:
>
> A consteval could very much help with a custom identifier. You could create a custom type by doing this:
> ```c++
> template <int tI>
> struct foo {...};
>
> using my_unique_type1 = foo<counter()>;
> ```
>
> Or for defining variables you may similarly do:
> ```c++
> template <int tI>
> inline bar& foo() {
> static bar res;
> return res;
> }
>
> auto& my_var = foo<counter()>();
> ```
>
> Personally, I think the consteval solution is much more powerful, but it may also be more complicated to implement.. The strongest argument that I can think of for the macro version (in addition to the complexity) is that the same syntax could be standardized in C, while the consteval cannot..
>
>
> // Robin
>
> On Mon, Aug 26, 2024, 19:42 Jeremy Rifkin <rifkin.jer_at_[hidden]> wrote:
>>
>> This was brought up by Chris Ryan in the previous email thread. This
>> might be interesting but as far as I can tell it's an unrelated topic.
>> The main use of __COUNTER__ is for unique identifiers which a
>> consteval function cannot help with. Unless there's interest in making
>> the preprocessor able to use C++ code.
>>
>> Jeremy
>>
>> On Mon, Aug 26, 2024 at 4:58 AM Robin Savonen Söderholm via
>> Std-Proposals <std-proposals_at_[hidden]> wrote:
>> >
>> > Just a thought before going too far here. Would it not be interesting to support the following from a meta programming perspective (which I assume the __COUNTER__ already is in some ways):
>> > ```cpp
>> > consteval int consteval_counter() noexcept {
>> > static int cur_count{};
>> > return cur_count++;
>> > }
>> > ```
>> >
>> > It can of course open up a new can of worms in regards to order of execution, but it could also potentially open up more ways for the user to customize stuff and do their own counter (or add multiple counters, if that would make any sense...)
>> >
>> > The value for "cur_count" would be independent for each translation unit, but one could also use this to create e.g. a compile-time random-number generator that could be seeded with a hash of the current file name or something like that.
>> >
>> > I am, however, not sure how difficult this would be to implement and if the benefits outweigh the costs.
>> >
>> > // Robin
>> >
>> > On Mon, Aug 26, 2024 at 11:11 AM Jens Maurer via Std-Proposals <std-proposals_at_[hidden]> 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
>> >>
>> >> > ...or have non-standard semantics.
>> >>
>> >> Improbable, given the implementation experience we've seen here.
>> >>
>> >> I'm in favor of not having a feature-test macro.
>> >>
>> >> 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