No problem, Corentin, take care!

I'm very much interested in P3258 (Formatting of charN_t)
<https://wg21.link/p3258>. I'm sorry for not having scheduled it sooner.
I've been juggling more than I can handle and have had little time for
my SG16 responsibilities recently; it has shown in how late I've been
scheduling things. I'll be able to devote more time again once I get a
couple of work items over the finish line in the next couple of weeks.

Tom.

On 10/23/24 2:25 PM, Corentin Jabot via SG16 wrote:
>
> fyi I won't be attending tonight. I need to take care of my mental health.
>
> please let me know if p3258 is something you are interested in
> pursuing or if I should not bother.
>
> cheers
>
>
> On Wed, Oct 23, 2024, 17:10 Victor Zverovich via SG16
> <sg16_at_[hidden]> wrote:
>
> Fully agree with Tom.
>
> - Victor
>
> On Wed, Oct 23, 2024 at 8:03 AM Tom Honermann via SG16
> <sg16_at_[hidden]> wrote:
>
> Concerns about std::mbstate_t fall under our purview. I expect
> LEWG to
> look to us for a recommendation of how to handle features that
> concern it.
>
> Tom.
>
> On 10/23/24 2:11 AM, Jens Maurer via SG16 wrote:
> > I think it is off-topic for SG16 to discuss this proposal at
> all.
> > There are no encoding concerns beyond those already answered for
> > std::format, and what the components of a std::fpos<T> are and
> > which sequence of characters is used to represent it and whether
> > you can (hypothetically) parse the representation to recover a
> > std::fpos<T> are all good questions --- that belong to LEWG,
> not SG16.
> >
> > And a data point: The convertibility requirement for
> std::fpos to
> > std::streamoff (C++98) predates the introduction of explicit
> conversion
> > operations (C++11), thus the only way to reasonably satisfy
> the explicit
> > conversion requirement was for implementations to provide an
> implicit
> > conversion.
> >
> > Jens
> >
> >
> > On 23/10/2024 02.06, 梁家铭 via SG16 wrote:
> >> Hi Corentin,
> >>
> >> The first version of draft (D3374R0) is to format the
> `fpos` as an integer directly, which can be confirmed by
> Victor. The reason why I finally add the state type is that
> Tom reminds me that it's not proper to neglect such a basic
> component by default and I think that really makes sense. This
> also makes me reflect that it's possibly not robust for stream
> to only output the integer, and that's why `.offset` is not
> thought as the solution. There is no difference for me to cast
> explicitly or call `.offset`.
> >>
> >> In today's talk, I'd like to share something about:
> >> + briefly cover what mbstate_t should do, as you may be
> already familiar with;
> >> + why C++ programmers generally think it's enough to use
> the integer, as a result of illusion from the implementations
> of streams that do text encoding;
> >> + we could provide such facility in the standard library
> for those programmers who concern the state, as long as we
> think mbstate_t is not a deprecated feature.
> >>
> >> For the formatting specification, there could be some
> better representations if `(pos, mbstate)` is not considered
> as a good one or even not the default one, and I'd like to
> discuss with you :). I know that mbstate_t couldn't be
> expected to be formatted in any meaning way, but it's enough
> to make it recoverable by the implementation. For me doing a
> round-trip is possibly the most thing we could do in the standard.
> >>
> >> Thanks for the feedback,
> >> Liang Jiaming
> >>
> >>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
>