[libc++][clang] Libc++ implements `std::from_chars` with default argument as one more overload, is it allowed?

[SainoNamkho]

https://eel.is/c++draft/charconv#from.chars-1 says the signature should be

constexpr from_chars_result from_chars(const char* first, const char* last,
                                       integer-type& value, int base = 10);

But is implemented as

llvm-project/libcxx/include/__charconv/from_chars_integral.h

Lines 222 to 233 in fcf341d

	template <typename _Tp, __enable_if_t<is_integral<_Tp>::value, int> = 0>
	inline _LIBCPP_CONSTEXPR_SINCE_CXX23 _LIBCPP_HIDE_FROM_ABI from_chars_result
	from_chars(const char* __first, const char* __last, _Tp& __value) {
	return std::__from_chars_atoi(__first, __last, __value);
	}
	template <typename _Tp, __enable_if_t<is_integral<_Tp>::value, int> = 0>
	inline _LIBCPP_CONSTEXPR_SINCE_CXX23 _LIBCPP_HIDE_FROM_ABI from_chars_result
	from_chars(const char* __first, const char* __last, _Tp& __value, int __base) {
	_LIBCPP_ASSERT_UNCATEGORIZED(2 <= __base && __base <= 36, "base not in [2, 36]");
	return std::__from_chars_integral(__first, __last, __value, __base);
	}

I'm not should if there's any legal ways to inspect this. And if the following code is well-formed, it does make a difference.
https://godbolt.org/z/vE95qzhEM

#include <charconv>

static_assert(requires {
    static_cast<std::from_chars_result(*)(const char*, const char*, int&)>(std::from_chars);
});

In addition, if this code is rejected, should the requires expression cause a hard error, or the code fail due to static_assert failure?

[philnik777]

I'm not aware of any way to detect this other than through non-conforming code, so I'd say it is a conforming implementation. Your code isn't conforming because you're forming a pointer to std::from_chars, which isn't an addressable function. http://eel.is/c++draft/namespace.std#6

[SainoNamkho]

I'm not aware of any way to detect this other than through non-conforming code, so I'd say it is a conforming implementation. Your code isn't conforming because you're forming a pointer to std::from_chars, which isn't an addressable function. http://eel.is/c++draft/namespace.std#6

I'm sorry for unintentionally dropping out the decltype when editing my initial post.

How about this? https://godbolt.org/z/rxdxqTExb

#include <type_traits>
#include <charconv>

static_assert(requires {
    typename std::type_identity_t<decltype(std::from_chars<int>)>;
});

(Msvc rejects it because the standard does not say it can be template, and Microsoft STL lists the overload exhaustively).

And I might argue that it is still unclear whether the code is conforming.

The paragraph you excerpts says

Unless F is designated an addressable function, the behavior of a C++ program is unspecified (possibly ill-formed) if it explicitly or implicitly attempts to form a pointer to F.

The meaning of attempts seems unclear and inconsistent in the standard regarding unevaluated contexts.
I found https://eel.is/c++draft/basic.lval#10

A program that attempts to modify an object through a nonmodifiable lvalue or through an rvalue is ill-formed.

and https://eel.is/c++draft/basic.lval#11

If a program attempts to access ([defns.access]) the stored value of an object through a glvalue through which it is not type-accessible, the behavior is undefined.

However, they don't mean https://godbolt.org/z/91vd513Pq

#include <type_traits>
const int i = 1;
// Reads are ruled out of _access_ when not odr-used but writes are not.
std::remove_reference_t<decltype(*reinterpret_cast<long*>(const_cast<int*>(&i)) = 2)> j = 3;

is ill-formed or undefined.

But https://eel.is/c++draft/expr.static.cast#4's

The conversion is ill-formed when attempting to convert an expression of class type to an inaccessible or ambiguous base class.

makes https://godbolt.org/z/dxxe8o3a5 ill-formed:

struct A{};
struct B : A, A{};
decltype(static_cast<A>(B{})) a;

The term form a pointer seems working syntactically, not about actually evaluating the expression, but https://eel.is/c++draft/class.cdtor#3

To form a pointer to (or access the value of) a direct non-static member of an object obj, the construction of obj shall have started and its destruction shall not have completed, otherwise the computation of the pointer value (or accessing the member value) results in undefined behavior.

is not likely to make

struct O {
    int* o;
};
struct A
{
    int a;
};

struct B : O, A
{
    B() : O(decltype(&this->a){}) {}
};

undefined.

@frederick-vs-ja How do you think of this?

[frederick-vs-ja]

As the restriction on taking addresses was added in C++20 (by P0551R3), should we guarantee the behavior of taking the address of std::from_chars in C++17? @philnik777

(Msvc rejects it because the standard does not say it can be template, and Microsoft STL lists the overload exhaustively).

And I might argue that it is still unclear whether the code is conforming.

As the exact form of the overload set is unspecifed, the well-formedness of std::from_chars<int> itself is unspecified, so the example using it can be considered non-conforming, even without the introduction of (non-)addressable functions.

The term form a pointer seems working syntactically,

I'd say "form a pointer" is not itself a term in the standard.

Anyway, it's unlikely that the intent is that taking address of function is only OK in unevaluated contexts. I think the intent should be relaxing the restriction on the exact forms of (non-addessable) standard functions, which also affects unevaluated contexts.

I think the standard wording is too terse on non-addressable functions. Perhaps we should explicitly identify possibly unevaluated function-to-pointer conversion or reference binding in [namespace.std]. An LWG issue or editorial issue seems needed.

[frederick-vs-ja]

The situation becomes chaotic if an overload set is consist of standard and program-defined functions.

I guess the following example needs to be well-formed. It seems to me that only the address of a program-defined function is taken.

#include <charconv>
#include <type_traits> 

namespace fvs {
template <class I, std::enable_if_t<std::is_integral_v<I>, int> = 0>
std::from_chars_result from_chars(const char*, const char*, I&) { return {}; }
}

int main()
{
    using std::from_chars; // perhaps shouldn't be considered
    using fvs::from_chars;
    auto p [[maybe_unused]] =
        static_cast<std::from_chars_result(*)(const char*, const char*, int&)>(from_chars);
}

Godbolt link

[philnik777]

As the restriction on taking addresses was added in C++20 (by P0551R3), should we guarantee the behavior of taking the address of std::from_chars in C++17? @philnik777

I don't think so. This has always been problematic, and I don't see the value in making any guarantees here. You already have to jump through hoops to make this work. P0551 basically just made it explicit in the standard.

[ldionne]

I believe the intent of the Standard is to let implementers do things like have different overloads instead of using a default argument. It is now clear that this intent is not fully captured by the existing wording (which only prevents people from taking the address of non-addressable functions), however I don't think this should be considered a bug in libc++ per se. At the very least, this isn't a guarantee we are willing to provide so we'd have a good chat with WG21 if they thought this was a legitimate use.

I would suggest opening a LWG issue to clarify the intent of the Standard. In the meantime, I'll close this since I don't think we want to change anything in libc++.

[frederick-vs-ja]

LWG4100 opened. But Daniel Krügler told me that the issue is likely to be closed as NAD and a proposal might be needed.