Date: Sun, 12 Dec 2021 15:45:37 -0600
On Sun, Dec 12, 2021 at 2:20 PM Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
> On 12/12/2021 21.00, Barry Revzin wrote:
> >
> >
> > On Sun, Dec 12, 2021 at 4:30 AM Jens Maurer <Jens.Maurer_at_[hidden]
> <mailto:Jens.Maurer_at_[hidden]>> wrote:
> >
> > On 11/12/2021 23.00, Victor Zverovich via SG16 wrote:
> > > Hi Tom and other Unicoders,
> > >
> > > Can we review an updated revision of P2286 (
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html> <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html>>)
> during the upcoming meeting since there is still chance that it can target
> C++23? This revision addresses the SG16 feedback, particularly around
> escaping (
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior
> <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior>
> <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior
> <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior>>).
> I think it's way more important and time sensitive than LWG issues related
> to fill.
> >
> > Why do we need a
> >
> > range_formatter
> > and
> > tuple_formatter ?
> >
> > Isn't it enough that the standard library provides partial
> > specializations of formatter<T> to offer the functionality?
> >
> > Jens
> >
> >
> > Fewer template instantiations, and users can use range_formatter<int> to
> help them format any range of ints if they want to do something internally
> themselves.
>
> But that range of ints will match formatter<R>, too, I guess?
> If formatter<R> derives from range_formatter<range_reference_t<R>>,
> using a formatter<R> seems to also instantiate range_formatter.
> If the latter doesn't exist, those template instantiations are
> saved.
>
Yes, but you only have to instantiate parse() once per (cvref-unqualified)
reference type rather than once per range type.
>
> > It's just more user friendly. They can use formatter<R> if they really
> want to too, this is just more direct.
>
> I don't understand.
>
> Could you point me to a section in the paper that specifically
> addresses that having both range_formatter<V> and a partial
> specialization for formatter<R> is "more user-friendly"?
> I thought those formatters were intended as helpers for
> std::format, anyway?
>
> Jens
>
There isn't a section in the paper for it, it was asked for in one of the
LEWG telecons. They are intended as helpers for std::format (indeed, they
have... no other use whatsoever), but when you're defining a formatter
specialization for your own type, and your type might have range members,
it could affect how you would implement your formatter specialization if
you actually want to go ahead and handle specifiers and the like.
Barry
> On 12/12/2021 21.00, Barry Revzin wrote:
> >
> >
> > On Sun, Dec 12, 2021 at 4:30 AM Jens Maurer <Jens.Maurer_at_[hidden]
> <mailto:Jens.Maurer_at_[hidden]>> wrote:
> >
> > On 11/12/2021 23.00, Victor Zverovich via SG16 wrote:
> > > Hi Tom and other Unicoders,
> > >
> > > Can we review an updated revision of P2286 (
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html> <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html>>)
> during the upcoming meeting since there is still chance that it can target
> C++23? This revision addresses the SG16 feedback, particularly around
> escaping (
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior
> <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior>
> <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior
> <
> https://brevzin.github.io/cpp_proposals/2286_fmt_ranges/p2286r4.html#escaping-behavior>>).
> I think it's way more important and time sensitive than LWG issues related
> to fill.
> >
> > Why do we need a
> >
> > range_formatter
> > and
> > tuple_formatter ?
> >
> > Isn't it enough that the standard library provides partial
> > specializations of formatter<T> to offer the functionality?
> >
> > Jens
> >
> >
> > Fewer template instantiations, and users can use range_formatter<int> to
> help them format any range of ints if they want to do something internally
> themselves.
>
> But that range of ints will match formatter<R>, too, I guess?
> If formatter<R> derives from range_formatter<range_reference_t<R>>,
> using a formatter<R> seems to also instantiate range_formatter.
> If the latter doesn't exist, those template instantiations are
> saved.
>
Yes, but you only have to instantiate parse() once per (cvref-unqualified)
reference type rather than once per range type.
>
> > It's just more user friendly. They can use formatter<R> if they really
> want to too, this is just more direct.
>
> I don't understand.
>
> Could you point me to a section in the paper that specifically
> addresses that having both range_formatter<V> and a partial
> specialization for formatter<R> is "more user-friendly"?
> I thought those formatters were intended as helpers for
> std::format, anyway?
>
> Jens
>
There isn't a section in the paper for it, it was asked for in one of the
LEWG telecons. They are intended as helpers for std::format (indeed, they
have... no other use whatsoever), but when you're defining a formatter
specialization for your own type, and your type might have range members,
it could affect how you would implement your formatter specialization if
you actually want to go ahead and handle specifiers and the like.
Barry
Received on 2021-12-12 15:45:53