refp

you are correct. (DISCLAIMER: I am the author of what you are referring to)

For those who are looking to understand what is going on, I would recommend the blog series I wrote -almost- more than half a decade ago at https://b.atch.se

Compiler intrinstics havet changed a lot since then, but the wording in the standard remains quite stable in this department

Disclaimer; I did not read your post in full (on set, working atm).

Edit: time flies, it has been more than half a decade.

A detailed post that shows how to implement a stateful meta-container that is usable where a constant-expression is required, effectively making it possible to store away different states during compilation of a program. The approach enables the world of meta-template programming to closely follow the semantics of imperative programming.

This post is part of the series regarding non-constant constant-expressions in C++, previous posts are linked below:

* http://b.atch.se/posts/constexpr-counter/

* http://b.atch.se/posts/non-constant-constant-expressions/

I just submitted a request to join the reflector where I know this is being discussed; nonetheless, information will be published on http://b.atch.se as soon as I have had time to write the contents of new posts.

I have been trying _very_ hard to get in contact with the folks that are discussing this approach; just preventing ADL constexpr tricks (through "friendly definitions") isn't enough.

I am still waiting for the relevant parties to reply to my emails, but an article explaining "everything" (and the different approaches (about 3 at the current time, in addition to "friendly definitions") will be published soon.

There is a lot of wording that has to be changed in order to prevent the semantics explained.

It is part of both, the technique described is not the only way to reach a solution for the given problem (implementing a counter usable in constant-expressions).

In other words; if one sees this as a "bug" in the ISO C++ Standard, the "problem" is a lot deeper than friendly definitions (the technique used in the post).

C++ is a complex language, where many rules touch upon other, and with that it is not surprising that some rules can be bent to allow behavior which was perhaps never intended.

Future posts (probably after part 3) will address the philosophy of the "exploit", other techniques that boil down to doing the same thing, as well as proposed (ISO Standard) wording to "fix" the "problem" - if that is the path being walked.

This is the second post in the series regarding "non-constant constant-expressions in C++" - http://b.atch.se/posts/non-constant-constant-expressions/

Feedback is more than welcome!

/Filip Roséen

> "This lack of dependency must inherently mean that it will yield the same value upon each invocation having the same set of arguments"

That quote was written in a "this is what most of us used to think" sort of way, it was never intended to be read literally - though maybe I should clearify the intent.

I certainly agree with your post, and your little hack is very cute; +1! :-)