On Mon, Jun 7, 2021 at 10:42 AM Hubert Tong <
hubert.reinterpretcast_at_[hidden]> wrote:

> [off-list: note CC] I'm not sending to the list this close to plenary but
> I would like to send a response to Tom before plenary starts.
>

[+list] Now that plenary is over...


> On Mon, Jun 7, 2021 at 1:13 AM Tom Honermann <tom_at_[hidden]> wrote:
>
>> On 6/6/21 8:15 PM, Hubert Tong wrote:
>>
>> I am not aware of implementation experience for this paper in
>> environments where characters significant to the interpretation of the
>> format string are not locale-invariant. There is, however, reason to
>> believe that an implementation can be realistically deployed to such
>> environments while giving some ability of the user to choose the text
>> encoding under which format strings are parsed. As it is, the paper uses
>> *format-string* and *wformat-string* as exposition-only types in the
>> signature of the `format` functions. It is possible for an implementation
>> to version these functions (across translation unit boundaries) through
>> embedding the text encoding information into these types. A mechanism such
>> as std::text_encoding::literal().mib() from P1885R5 (which has not yet
>> advanced to plenary) could be used.
>>
>> That mechanism does not appear to be an option for the vformat_to() or
>> vformat() overloads since their signatures do not include *format-string*
>> or *wformat-string*. It doesn't look to me like that information can be
>> smuggled through the types of basic_format_args or basic_format_context
>> either, though perhaps they could be used to store a value that indicates
>> the literal encoding.
>>
> Thanks for pointing this out; looks like more to plan looking into for the
> implementation on my end.
> With a per-TU limitation, working some magic into make_format_args will
> work (I think). I admit to not being an experienced library implementer.
>
>> [P1885 is currently scheduled for consideration by LEWG during its
>> 2021-08-03 telecon]
>>
> Thanks for the info.
>
>>
>> The above approach is perhaps more limiting than strictly necessary upon
>> extensions that allow the translation of string literals to be changed
>> within a translation unit. It is noted that P1885R5 exposes the literal
>> encoding as a consteval function, which is compatible with
>> context-sensitive evaluation by the implementation. In case there is an
>> appetite to allow for such context-sensitivity for format strings, it is
>> probably the case that updating the text to allow for exposition-only extra
>> parameters in the signature is purely a specification matter and does not
>> affect implementations where such scenarios do not occur. It is also rather
>> likely that implementations which do employ such extra parameters are
>> conforming anyway (because the extra parameters are only observable when a
>> user applies an extension). Nevertheless, the paper may be just the
>> beginning of a number of changes that are candidates for being considered
>> retroactive to C++20.
>>
>> It looks to me like construction of a basic_format_context
>> specialization is effectively unspecified due to lack of constructors and
>> the presence of exposition only data members. Perhaps more of it can be
>> specified as exposition only.
>>
>> Incidentally, I think the specification of basic_format_context may be
>> missing an exposition only std::locale data member corresponding to any
>> passed to a formatting function.
>>
> I think, implementation-wise, something can still be done with
> make_format_args for this. Not sure how much of what's needed will fit
> within the leeway of the wording.
>
>>
>> TL;DR: The paper sets a direction (but does not actually spell out that
>> it does) of using the encoding associated with literal translation for
>> parsing format strings. The work around improving the management and
>> handling of said encodings is still ongoing; therefore, where this paper
>> leads us is not as clear as it could be given additional time.
>> Nevertheless, it is probably the case that further incremental improvements
>> can be made on top of this paper without compatibility breakage for
>> implementations that choose to deploy earlier. In certain environments,
>> quality-of-implementation around this paper may be dependent on additional
>> improvements to the specification. Since this paper is being considered to
>> be retroactive to C++20, it is reasonable to expect that improvements of
>> the aforementioned kind would also be considered for retroactive inclusion
>> as they are discovered.
>>
>> I agree, though the words "probably the case" give me pause. Regardless,
>> at least for me, this does not translate to a desire to delay adopting this
>> paper.
>>
> I agree that establishing sufficient consensus on the broad design intent
> is important.
>
> Thanks.
>
> -- HT
>
>> Tom.
>>
>>
>>