C++20's std::format is so picky

[deleted account xyzzy]

Well, Visual Studio 2022's implementation of std::format is picky.

The following compiles without even a twitch:

import <iostream>;
import <format>;

int main()
{
   int var    { 7 };

   std::cout << std::format("{} was assigned an initial value\n", var);
}

Yet change the "{}" to "{ }" and VS upchucks a compile-time error:

C7595 'std::_Basic_format_string<char,int &>::_Basic_format_string': call to immediate function is not a constant expression

A compile-time error is better than a run-time one. But PUH-LEEZE! Such a picayune thing to whinge about.

I know the C++ standard used the {fmt} library for the implementation, so I suspect this is not a C++ stdlib issue.

Nice the admin finally made the preview work for a new post, thank you!, though the format tools still are MIA when creating a new topic.

[Peter87]

I'm not sure but since you can customize the format for your own types I suspect spaces and other whitespace characters might make a difference so it's probably better to be strict to avoid any surprises later.

[Peter87]

... I found a situation where space matters.

std::format("{0: }", myNumber)

space: Indicates that a leading space should be used for non-negative numbers, and a minus sign for negative numbers.

https://en.cppreference.com/w/cpp/utility/format/formatter#sign.2C_.23.2C_and_0

[seeplus]

space matters in a format spec. {} is empty, { } is not.

[deleted account xyzzy]

@Peter87, don't need the leading zero as the arg-id before the colon in the {} format specifier, "{: }" is accepted by VS without complaints.

I just wish the error message VS throws up wasn't so IMO techy gobbledygook non-explanatory.

[kbw]

I'm not sure but since you can customize the format for your own types

You can with https://github.com/fmtlib/fmt.

[seeplus]

@kbw - that web link doesn't exist - Page not found.

You can code for your own format for std::format. For an introduction to this see:
https://www.cppstories.com/2022/custom-stdformat-cpp20/

[mbozzi]

I just wish the error message VS throws up wasn't so IMO techy gobbledygook non-explanatory.

Does anyone feel like teaching GCC or Clang to understand these format strings?

[Peter87]

Just be patient...

[deleted account xyzzy]

So far the people doing the GCC and Clang implementations seem more interested in getting C++23 working than C++20 core and library features.

It's 2022 and still VS is the sole implementation that is 100% compliant with C++20.

https://en.cppreference.com/w/cpp/compiler_support/20

All GCC has to do is steal {fmt}. The C++ ISO Committee did that for the <format> approval.

Why modules is another "we can't fully crack this nut" is rather disappointing as well. Partial support don't cut it years after the fact of approval.

[mbozzi]

I was really talking about the diagnostic messages. I had forgotten support is lacking.

If the aim to eventually replace cout with a std::format variant (std::print?) it would be nice for the compiler to give less opaque error messages, as a special case.

In other words I want something analogous to -Wformat - something that gives better diagnostics when the format string is screwed up.

[deleted account xyzzy]

From the start with C++20 and VS -- VS 2019 FYI, VS 2022 hadn't been released yet in wide distribution -- I found the error messages with std::format to be less than clear, they were decidedly un-helpful.

That was when std::format bugged out at run-time, before the C++ stdlib changed the behavior to be compile-time. Learning the byways and peculiarities of C++20 is intimidating enough even with plain language errors.

I don't believe getting clear and understandable error messaging should be a compile flag, on or off. But what do I know.

I ain't one of the compiler implementation team members, so maybe it is harder than it might seem to be.

VS Intellisense quite a lot goes buggy with modules, reporting things are wrong when doing a compile everything is hunky-dory.

[seeplus]

As GCC and Clang have had issues providing std::to_chars/from_chars with floating point and std::format uses these, is this a reason why GCC and Clang haven't yet released std::format?

[Peter87]

I have no idea if anyone is working on it but at least it has been reported as a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104166

Also found this interesting discussion: https://gcc.gnu.org/pipermail/libstdc++/2021-May/052559.html

Ed wrote:

I was looking into this (not that I have time) and decided that grabbing
fmt is the best way forward for libstdc++ if the licensing could work.

Jonathan wrote:

Maybe, although an independent re-implementation of the spec has big
advantages for the quality of the spec.

And this one: https://github.com/fmtlib/fmt/issues/1686

DBJDBJ wrote:

I assume clang, gnu and msft will take from you that header on some date? Or they will just go ahead and implement it and then ask you to approve? And what about compiler vendors? Is WG21 coordinating any of this?

foonathan wrote:

They will implement it mostly from scratch using the formal specification here: http://eel.is/c++draft/format

DBJDBJ wrote:

I know that is possible to do. But. Is it not to be expected Victor's implementation is of the best quality? Tried and tested and such ... None of "them three teams" writes "bugless code", so why not just cooperating here on the reference implementation?

foonathan wrote:

An issue with fmt is that it has a lot of workarounds for various older compilers and weird OSes. A standard library implementation of a C++20 feature probably has fewer compatibility issues to worry about. They also need to _Uglify the implementation, so they can't directly copy it anyway.

They also mention difference between {fmt} and std::format. And to my knowledge there has been at least two accepted proposals since C++20 that introduces small breaking changes compared to the original C++20 specification.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2216r3.html
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2418r2.html

[seeplus]

I have no idea if anyone is working on it but at least it has been reported as a bug.

That's interesting. The std::format bug no. is 104166. This has a dependency on bug 88322 being fixed - but bug 88322 has a dependency on bug 104166 being fixed...

"she can'nae take any more"

[Peter87]

I think you are reading it wrong. The "Depends on" field is empty for 104166.
It "blocks" 88322 but that is because 88322 depends on it.

[seeplus]

https://gcc.gnu.org/bugzilla/showdependencygraph.cgi?id=104166

Doesn't this show that 104166 depends upon 88322

and
https://gcc.gnu.org/bugzilla/showdependencygraph.cgi?id=88322

shows 88322 depends upon 104166??

or I am completely out of my mind today?

[Peter87]

In both graphs the arrow goes from 104166 and points at 88322.

So I think you should read 104166 --> 88322 to mean that 88322 depends on 104166 because that is consistent with what the other pages are saying.

[deleted account xyzzy]

Heh, the C++20 One Ranges Proposal (P0896R4) has a rather amusing preamble:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0896r4.pdf