Unexpected error when using libc++ (call to deleted function 'from_chars')

[aleck099]

Code

Compile with clang++ -std=c++17 -stdlib=libc++

#include <charconv>
#include <string>
#include <stdexcept>

template<typename T>
T decode_num(std::string_view s) {
    T r;
    auto ec = std::from_chars(s.data(), s.data() + s.size(), r);
    if (ec.ec == std::errc())
        return r;
    else
        throw std::runtime_error("decode_num");
}

int main() {
    const char fs[]{ "0.87" };
    float r = decode_num<float>(fs);
    return 0;
}

Error:

t1.cpp:8:15: error: call to deleted function 'from_chars'
    auto ec = std::from_chars(s.data(), s.data() + s.size(), r);
              ^~~~~~~~~~~~~~~
t1.cpp:17:15: note: in instantiation of function template specialization 'decode_num<float>' requested here
    float r = decode_num<float>(fs);
              ^
/usr/bin/../include/c++/v1/charconv:113:19: note: candidate function has been explicitly deleted
from_chars_result from_chars(const char*, const char*, bool, int = 10) = delete;
                  ^
/usr/bin/../include/c++/v1/charconv:588:1: note: candidate template ignored: requirement 'is_integral<float>::value' was not satisfied [with _Tp = float]
from_chars(const char* __first, const char* __last, _Tp& __value)
^
/usr/bin/../include/c++/v1/charconv:595:1: note: candidate function template not viable: requires 4 arguments, but 3 were provided
from_chars(const char* __first, const char* __last, _Tp& __value, int __base)
^
1 error generated.

Versions:

Clang / libc++: 14.0.6

Other information

Error does NOT occur when:

• compile with GCC or MSVC
• without -stdlib=libc++

[EugeneZelenko]

Could you please try 15 or main branch? https://godbolt.org should be helpful.

[philnik777]

std::from_chars isn't implemented yet. Please check https://libcxx.llvm.org/Status/Cxx17.html (or the status page where the corresponding paper is listed) before reporting unimplemented papers as bugs. For a fast check you can also look at the feature test macros (in this case __cpp_lib_to_chars, which isn't set).

[ceztko]

To whom it may concern: the paper partially implemented is P0067r5. It proved to be a pain to implement to MSVC team (source code) and possibly it was implemented in gcc with an hack. Do you have an idea on how/when this could be delivered to llvm as well? I would definitely not blame the team if you follow the gcc path, after all only a fraction of the potential users would need the round trip feature of to_chars, from_chars. To all other people that just want to use std::from_chars I implemented a small incomplete filler that uses fastfloat behind the scenes.

[philnik777]

To whom it may concern: the paper partially implemented is P0067r5. It proved to be a pain to implement to MSVC team (source code) and possibly it was implemented in gcc with an hack. Do you have an idea on how/when this could be delivered to llvm as well? I would definitely not blame the team if you follow the gcc path, after all only a fraction of the potential users would need the round trip feature of to_chars, from_chars. To all other people that just want to use std::from_chars I implemented a small incomplete filler that uses fastfloat behind the scenes.

The fastest way to get it is to implement it and provide the implementation to libc++. Otherwise you have to hope that someone feels like implementing it. For the most part, libc++ is being worked on by volunteers. Only a relatively small part of the code is provided by any companies.

[ceztko]

I understand, thanks for pointing it out. Stephan T. Lavavej of MSVC team explained he worked about 1 year on this, which should be scaring to anyone with a job or any other activity. This also a reason why hacks or code "stealing" (respecting licenses, OFC) should be seriously considered to implement this paper. Sorry but I'm not devoted enough to llvm to be a contributor, especially on this subject: with my post I wanted to leave a note to anybody passing by explaining why std::from_chars is still not in libc++ and offer other viable options.

[mordante]

Even when using external code it's not a trivial task. Stephan contributed MSVC's version of to_chars to libc++. I've changed that code to libc++ code was quite a bit of work. (Obviously a lot less work than doing the entire work myself.)
When using external code there still are a lot of tests to be written. So yes this is a large project. I might take it up at some point, but it's low on my priority list. Not because it's not important, but just due to the amount of work.

[h-vetinari]

Stumbled over this while looking for the status of P0067R5; took me a while to unearth some old comments on this topic in https://reviews.llvm.org/D70631:

@h-vetinari: I was under the impression that 87c0160 did most of the work for from_chars?

@mordante: Thanks for both links I wasn't aware of this effort!
At the moment I'm too busy with <format> to look at from_chars, but this is useful when somebody starts working on from_chars.
(I might look at it when I finished the larger projects I'm working on.)

I guess we can all but hope¹ that the stack of C++20/23 <format> work will be done eventually. 😅

Footnotes

1. I consider it far outside my skillset to try to contribute myself here, unfortunately; even then, I'm still waiting for the move to GH, really not interested in working with Phab. ↩

[mordante]

I guess we can all but hope1 that the stack of C++20/23 <format> work will be done eventually. sweat_smile

That's almost done. The large part left is implementing the missing chrono parts so I can add formatters for these parts. Unfortunately I feel the library support for <format> is lacking, so guess who's working on papers to rectify that ;-)

You probably have noted I've a strong interest in the std and std.compat module too.

Adding support to from_chars is still on my todo list, but it's still low on that list and other new C++26 features may get a higher priority. I work on libc++ as a volunteer so things that I care about will get a higher priority.

[h-vetinari]

I work on libc++ as a volunteer so things that I care about will get a higher priority.

Completely understandable! :)

[h-vetinari]

I'm wondering if it wouldn't make sense to keep this issue open as a tracker for finishing the implementation of P0067R5, particularly the from_chars part? It already has a bunch of relevant context and there's no other issue for that¹.

Footnotes

1. Yes, I know that there's a status page, but that page does not contain useful references like 87c0160, for example. ↩

[mordante]

I prefer to keep it closed, we don't use the issue tracker to track libc++'s implementation status. We have the status page for that. Having some missing features as a bugs will cause us to forget closing bugs.