Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

formatter simply inheriting from built-in formatter is not recognised #4036

Closed
gnbond opened this issue Jun 27, 2024 · 1 comment · Fixed by #4055
Closed

formatter simply inheriting from built-in formatter is not recognised #4036

gnbond opened this issue Jun 27, 2024 · 1 comment · Fixed by #4055

Comments

@gnbond
Copy link

gnbond commented Jun 27, 2024

libfmt 10.2 / gcc 13

I have a string-like class implicitly-convertible to std::string_view. Based on older documentation I'd expect that to Just Work in fmt::format()but I see from other issues that matching on implicit conversion has been disabled. Annoying, but fair enough.

When I create a fmt::formatter specialisation for my class that simply inherits fmt::formatter<string_view>, this does not work, fmt::format still considers S to be an un-formattable type.

template<>
class fmt::formatter<S> 
    : public fmt::formatter<std::string_view> {};

https://godbolt.org/z/aMqqWaso9

The equivalent code using std::formatter works ok: https://godbolt.org/z/T7zzKzzf3

@vitaut
Copy link
Contributor

vitaut commented Jun 27, 2024

Right now the string_view formatter only accepts string_view and not objects convertible to it but I think it's reasonable to relax this.

Arghnews added a commit to Arghnews/fmt that referenced this issue Jul 7, 2024
Fixes fmtlib#4036
This formatter specialization with base::format means a class implicitly
convertible to std::string_view will now be converted by this format
function before being passed to the fmt::string_view format function.
This wouldn't work previously as the compiler may only perform one
implicit conversion, and we need 2 here (from our type, to
std::string_view, to fmt::string_view).
Arghnews added a commit to Arghnews/fmt that referenced this issue Jul 7, 2024
Fixes fmtlib#4036
This formatter specialization with base::format means a class implicitly
convertible to std::string_view will now be converted by this format
function before being passed to the fmt::string_view format function.
This wouldn't work previously as the compiler may only perform one
implicit conversion, and we need 2 here (from our type, to
std::string_view, to fmt::string_view).
Arghnews added a commit to Arghnews/fmt that referenced this issue Jul 13, 2024
Fixes fmtlib#4036
This formatter specialization with base::format means a class implicitly
convertible to std::string_view will now be converted by this format
function before being passed to the fmt::string_view format function.
This wouldn't work previously as the compiler may only perform one
implicit conversion, and we need 2 here (from our type, to
std::string_view, to fmt::string_view).
mtremer pushed a commit to ipfire/ipfire-2.x that referenced this issue Aug 15, 2024
- Update from version 11.0.1 to 11.0.2
- Update of rootfile
- Changelog
    11.0.2
	- Fixed compatibility with non-POSIX systems
	  (fmtlib/fmt#4054,
	  fmtlib/fmt#4060).
	- Fixed performance regressions when using `std::back_insert_iterator` with
	  `fmt::format_to` (fmtlib/fmt#4070).
	- Fixed handling of `std::generator` and move-only iterators
	  (fmtlib/fmt#4053,
	  fmtlib/fmt#4057). Thanks @Arghnews.
	- Made `formatter<std::string_view>::parse` work with types convertible to
	  `std::string_view` (fmtlib/fmt#4036,
	  fmtlib/fmt#4055). Thanks @Arghnews.
	- Made `volatile void*` formattable
	  (fmtlib/fmt#4049,
	  fmtlib/fmt#4056). Thanks @Arghnews.
	- Made `Glib::ustring` not be confused with `std::string`
	  (fmtlib/fmt#4052).
	- Made `fmt::context` iterator compatible with STL algorithms that rely on
	  iterator category (fmtlib/fmt#4079).

Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants