On Tue, Oct 22, 2024 at 8:24 PM Tom Honermann via SG16 <
sg16_at_[hidden]> wrote:

> SG16 will hold a meeting *tomorrow*, Wednesday, October 23rd, at 19:30
> UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20241023T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>
> ).
>
> The agenda follows.
>
> - P3374R0: Adding formatter for fpos<mbstate_t>
> <https://wg21.link/p3374r0>
> - P2019R7: Thread attributes <https://wg21.link/p2019r7>
>
> P3374R0 comes to us courtesy of Liang Jiaming and seeks to add formatting
> support for std::fpos<std::mbstate_t>. SG16 has not previously reviewed
> this proposal, but previous discussion occurred on the std-proposals
> mailing list in the thread starting here
> <https://lists.isocpp.org/std-proposals/2024/07/10667.php> and on the
> SG16 mailing list in a thread starting here
> <https://lists.isocpp.org/sg16/2024/08/4415.php>. Please try to review
> those before the meeting (and I again apologize for such late notice).
> std::mbstate_t is an implementation-defined type, so we can't legislate
> much about its representation in formatted output, but we can provide
> guidance, particularly with regard to whether formatted values of the type
> should be sufficient to reconstruct values in a hypothetical scanner such
> as that proposed by P1729 (Text Parsing) <https://wg21.link/p1729>.
>

There is very little SG-16 material here (ie, no text or encoding concerns
- this is just a formatter for an io-related facility - even if we think
mbstate_t is in our purview).
The subsequent observations are not SG-16 related

- There is no motivation given for the printing of the mbstate_t - Or
really no motivation for the paper but one can imagine printing the fpos
offset to be useful
mbstate_t is very much an implementation detail and we should not expect it
to be useful to anyone but the implementation - so we should not expect it
to be printable in any meaningful way.
And we should want to keep it that way because implementation strategies
are going to depend on the set of supported execution encodings.

- If there _was_ a motivation for it, I'd rather it be a separate flag
rather than defaulting to some invented representation ( (pos, state) is
proposed) (as you point out there are round tripping concerns for it)
- Alternatively the debug flag (?) could be used for that.

But critically, the main motivation (afaict) could be solved by adding an `
offset` member function to fpos(), returning a streamoff,
which is a much easier and flexible solution
https://compiler-explorer.com/z/WsTKs88Kb


Cheers


> P2019R7 was reviewed by SG16 during the 2024-09-25 meeting in which the
> following polls were taken:
>
> - Poll 2: P2019R7: Name hint should be provided in the ordinary
> literal encoding.
> - Attendees: 8
> -
> SF
> F
> N
> A
> SA
> 3
> 1
> 3
> 1
> 0
> - Weak consensus.
> - Poll 3: P2019R7: Name hint should be provided as an NTMBS in the C
> locale encoding.
> - Attendees: 8
> -
> SF
> F
> N
> A
> SA
> 1
> 5
> 1
> 0
> 1
> - Consensus
>
> The guidance provided regarding encoding of the name hint is fairly clear
> despite some continued opposition, so new information should be provided in
> order to reopen that discussion. Continued discussion is warranted for
> other concerns raised regarding POSIX vs Windows platforms and the use of
> std::string_view. We'll focus first on those topics and then any other
> concerns that are raised.
>
> Tom.
>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>