On Wed, Oct 23, 2024 at 2:06 AM 梁家铭 <liangjiaming_at_[hidden]> 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`.
>

I'd like to push back against that.
There is currently no way to observe an mbstate. The only operation C
defines on it is to query whether it is in the initial shift state. There
is also nothing you can do with it as it is an implementation detail.
Whatever state it might have is non-portable, and not actionable.
That it technically exists does not mean that it should be observable.
std::print should not expose things that cannot otherwise be queried. The
black box nature of mbstate is very much intentional. It's certainly not
deprecated, but it is not user-facing either.

I see two ways forward
 - add a function that extracts the offset
 - add a simple formatter that outputs the offset, and nothing else.



> 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
>
>