[libcxx-commits] [PATCH] D115989: [libc++][format] Disable default formatter.

Mark de Wever via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Sat Dec 18 12:26:27 PST 2021


Mordante marked 2 inline comments as done.
Mordante added inline comments.


================
Comment at: libcxx/test/std/utilities/format/format.formatter/format.formatter.spec/types.compile.pass.cpp:67-68
+    requires(F f, std::basic_format_parse_context<CharT> pc, T u, std::basic_format_context<CharT*, CharT> fc) {
+  { f.parse(pc) } -> std::same_as<typename decltype(pc)::iterator>;
+  { f.format(u, fc) } -> std::same_as<typename decltype(fc)::iterator>;
+};
----------------
Mordante wrote:
> Quuxplusone wrote:
> > Would it be useful to verify here that `std::as_const(f).format(u, fc)` is also OK?
> > (Recall our earlier discussion of how standard formatters should be const-friendly because eventually they'll be required to be constexpr-friendly. This could be tucked behind an `#ifdef _LIBCPP_VER`.)
> No that's not useful since at the moment those functions aren't `const` and can't be `const`.
> When the width is formatting argument its value is resolved in `format` and modifies the object. This obviously needs to be resolved when your LWG3636 gets accepted. But even if it doesn't get accepted that change probably is useful when implementing P2286 "Formatting ranges".
> 
> So I've already investigated how I want to resolve this. However I first like to know the final resolution for LWG3576 "Clarifying fill character in std::format". When implementing its resolution it's a good time to make sure these functions can be `const`.
@Quuxplusone Fun fact I just see P2286R4 already cites and assumes LWG3636 will be accepted and requires the format function to be `const` qualified.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115989/new/

https://reviews.llvm.org/D115989



More information about the libcxx-commits mailing list