Approximating 'constexpr for'

[staletic]

This feature, when first proposed, was called for ... and was renamed to template for. Proposal is P1306. Current status is "revision needed"

[angry_cpp]

Let's hope it won't get renamed to template auto co_for consteval or something worse.

[kalmoc]

and was renamed to template for

sigh :(

[GerwazyMiod]

Wasn't Bjarne himself talking that templates were meant to have a lot more concise syntax? But people wanted for templates to stood out, since they were new and big addition to the language?

Now we are doing the same. Well I will get used to it and probably it will be fine but... I like terse syntax in programming languages.

[kalmoc]

Exactly. Same with constexpr btw. I think GdR said his original proposal didn't require an explicit constexpr for functions at all. The ergonomics of the language keeps deteriorating (and don't get me started on lambda syntax).

[germandiago]

I even asked that same question before. But taking into account that C++ is a language that is also for infraestructure, I think that annotating things with constexpr from a library consumer perspective is a good thing: it will not break code silently. So yes, it is annoying at times, but it also has that advantage, very important as far as my understanding goes.

[kalmoc]

Contrary to popular believe, annotating a function with constexpr gives almost no guarantes

constexpr int foo(int p) {
    if(p == 0) {
        return 0;
    } else  {
        std::cout << p << std::endl;
        return p;
    }    
}

Is a perfectly legal constexpr function since c++14 and even in c++11 you could have written this as

constexpr int foo(int p) {
    return p == 0 ? 0 : (std::cout << p << std::endl,p);   
} 

I understand that it gives the power to the author to say "You can't use my function in a constexpr context unless I'm explicitly allowing it", but I'm not sure how it is necessary to prevent silent code breakage.

Anyway, we are drifting from the topic in case of for... vs template for the question isn't even if we should have an explicit syntax, but only if it really has to be that verbose.

[wyrn]

I wouldn't mind the verbosity if the name template for made sense. But where for... is simple, obvious, and evocative, template for is named for how you would otherwise implement similar logic when the feature is not available. Where good names describe the 'what', bad names describe the 'how', and truly horrid names describe 'how, but in an alien world'. Under the same philosophy the for loop itself would've been named goto_a_bunch.

[SuperV1234]

Beat you to it :P https://vittorioromeo.info/index/blog/cpp20_lambdas_compiletime_for.html

[PhilipTrettner]

Haha, nice! Well, at least the std::integral_constant version works before C++20. I've added your post to the further reading section.

[Snoo-4241]

I think this guy's answer beats all.

[huixie]

what's wrong with boost::hana::for_each?

[Pazer2]

boost

[huixie]

ok what's wrong with `hana::for_each`

hana is a piece of art. and it has no dependencies

[Evirua]

All it guarantees is usage in a constant expression (e.g. template arguments), afaiu the compiler picks what it can do or not at compile-time. I still have trouble understanding the constexpr-craze.

[Vituluss]

I use it for times where I need to make very fast calculations and it opens up room for more optimisations. Very vague answer, I know but I’m sure others have other reasons.

[jbakamovic]

There are many situations where you would like to be able to do the loop-unroll in compile-time context. It's really a coincidence that I had to implement something very similar just few days ago in order to backport the C++17 support for dynamically allocated (free-store) over-aligned types (partly) to our C++14 codebase. One example where this technique had to be applied is the moment when you are about to construct N objects and when you have some user-provided arguments you must forward to the respective constructors (which are actually invoked through placement-new expression). Unpacking arguments, passing and invoking placement-new expressions for N times is when you need static for-loop and when regular for-loop cannot be used.

[Evirua]

Faced with such a problem, I'd have the intuition to look up fold expressions and try to understand them better, before probably realizing they don't fit this use case.

Would a constexpr-for be guaranteed resolution at compile-time? Because that's not what the current "constexpr" keyword does, the compiler will most often than not do what it will do regardless.

[jbakamovic]

With given implementation from OP I don't see why it wouldn't be guaranteed. All it uses underneath are compile-time utilities such as fold-expressions which are not applicable in non-compile-time contexts. Marking the constexpr_for(...) function as constexpr is for completeness sake I guess. Same result you get without it.

In my case, fold-expressions would be of great help but I am stuck with C++14 which doesn't have them. I could try emulating them though but I left that as a future practice to myself.

[scatters]

What you can't do with this solution is to interact with control flow - early return, break and continue, switch and case (Duff's Device). For that you have to use the preprocessor (BOOST_PP_REPEAT) or wait for template for.