Is there a specific reason to not constexprify Dragonbox?

[jk-jeon]

Is there a specific reason to not constexprify Dragonbox? If not, I believe it should be not terribly difficult to do so, because as far as I know the only real obstacle is that some intrinsics are not constexpr. But we can just wrap those intrinsics with if (!is_constant_evaluated()) and provide fallback implementations along with that. I'm experimenting myself with the recent master branch, and I guess Dragonbox is fine while it fails at this line, I do not know why.

Another issue is that the compiler is whining about static constexpr tables inside constexpr functions being static. (See e.g., https://stackoverflow.com/questions/62458079/static-constexpr-variables-in-a-constexpr-function.) Honestly I think this is a sort of nonsensical language restriction, but well, it is like that. A simple solution is to move those tables out of the functions.

[alexezeder]

Since I was responsible for the recently implemented constexprification of FP formatting, I guess I can try to answer that.

Is there a specific reason to not constexprify Dragonbox?

I don't have a specific reason for this, it was just mentioned by @vitaut that the most feasible approach is to use Dragon4 at compile-time. I agreed with this because Dragonbox FP formatting code seems complicated for me, thus it could have some ideas that cannot be constexprified easily. Also, this algorithm is used only for numbers without additional formatting specs, if I'm correct. Besides, who knows, maybe Dragonbox wouldn't be fast at compile-time the same way it's fast at runtime, this should be benchmarked, of course.

If not, I believe it should be not terribly difficult to do so

Sure, but it requires some work, additional work considering choosing the most feasible approach. I'm open to making Dragonbox available at compile-time 😉, but I don't think it would help {fmt} somehow.

Another issue is that the compiler is whining about static constexpr tables inside constexpr functions being static

Yeah, it's a familiar problem... probably for everyone who tried to make their code constexpr. 🤦

[jk-jeon]

As I mentioned, I was already able to make Dragonbox constexpr, but since it is relying on large static tables it probably works only with FMT_HEADER_ONLY. For whatever reason I thought it was Grisu instead of Dragon4 that is being used right now, so I thought this restriction is still there with the current implementation. Now I get that it's not the case, and it seems very reasonable to relying on Dragon4 instead.

@vitaut You can just close this issue, if you don't have further comments.

Actually, I thought that compilers are able to optimize this code (based on the fact that this approach is already used in the library - power_of_10_64 or bsr2log10), but I was wrong making this assumption: https://godbolt.org/z/KWYhcqKxn (Clang ❤️).

BTW, yeah, I was also very disappointed with this. Probably because adding static data that is not explicitly asked by the programmer is something compilers are not recommended to do? I don't know. Sounds silly to me to be honest, just like the fact that static is forbidden in constexpr context...

[vitaut]

I don't have much to add to what @alexezeder wrote. I think Dragon4 is OK for now but if it proves to be slow in terms of compile time affecting real use cases we could look into ways to optimize it in the future, possibly by constexprifying Dragonbox.