On Tue, May 21, 2024 at 6:25 PM Tom Honermann <tom_at_[hidden]> wrote:

> On 5/21/24 9:54 AM, Inbal Levi wrote:
>
> > BTW since this is related to text processing should SG16 look into it
> and provide recommendation(s)?
> Actually, that's a good point. Thanks for suggesting this, Victor.
>
> I'm CCing SG16 and the chair:
> *Tom* - do you think this requires a discussion in a telecon of your
> group, or do you think SG16 could pitch in with opinions using the ML
> review process?
>
> I don't think SG16 needs to weigh in on this. The intended behavior is
> clear and the existence of valid-but-negative code unit values is a reality
> that we can't change. I think LWG is well equipped to handle this issue.
>
Agreed

> Tom.
>
>
>
>
> Best Regards,
> Inbal Levi
>
> ISO C++ LEWG Chair & Israeli NB Chair
> C++Now Program Chair & CoreC++ Conference Organizer
>
>
> On Tue, 21 May 2024 at 14:11, Jens Maurer <jens.maurer_at_[hidden]> wrote:
>
>>
>>
>> On 21/05/2024 12.44, Jonathan Wakely via Lib-Ext wrote:
>> >
>> >
>> > On Mon, 20 May 2024 at 19:05, Inbal Levi <sinbal2l_at_[hidden] <mailto:
>> sinbal2l_at_[hidden]>> wrote:
>> >
>> > Hello all,
>> > In this week's review, we would like to ask for your input on
>> forwarding a paper to an electronic poll.
>> >
>> > P3223R0 <https://wg21.link/P3223R0>: Making
>> std::basic_istream::ignore less surprising
>> > (by Jonathan Wakely)
>> >
>> > This will be done in two stages:
>> > *_Stage 1 (current stage)_*: Vote on the preferred solution
>> > Stage 2: (will follow once the solution is decided) vote on
>> shipping vehicle (26/DR)
>> >
>> >
>> > ***
>> >
>> > *_Solutions proposed in the paper:_*
>> >
>> > 1. Change |ignore| to handle negative |delim| values
>> >
>> >
>> > -1, only a partial remedy.
>>
>> -1, it's a hack
>>
>> >
>> > 1. Split |ignore| into two functions and
>> change |delim| to |char_type|
>> >
>> >
>> > -1, breaking change.
>>
>> -1, no need for breakage of this magnitude
>>
>> >
>> > 1. *Add an overload of |ignore| that takes a |char_type|*
>> >
>> >
>> > +1, this is my preferred option, although I'm now leaning towards "this
>> new overload could be specified as present only when |char_type| is
>> |char|." i.e. don't add the new overload to the primary template, only the
>> char specialization.
>>
>> +1, but only when "char_type" is "char". Unlikely to break code.
>>
>> >
>> > 1. *As above, but constrain the new overload to prevent
>> ambiguities*
>> >
>> > +0, I think the constraints are overkill, and I think cases that become
>> ambiguous should be fixed to unambiguously pass either int_type or
>> char_type, not some other integral type. Also, if "we" (either WG21 or
>> implementers) decide to backport this as a DR for older standards, the
>> constraints are a bit more awkward to implement without concepts pre-C++20.
>>
>> +0, overkill.
>>
>> Jens
>>
>>
>> > I will try rebuilding a few hundred open source packages to see if the
>> ambiguities are common in practice.
>> >
>> >
>> >
>> >
>> > The author recommends *_either 3 or 4,_ so let's focus votes on
>> these options.*
>> > However, if you're in favor of another option, please vote so and
>> specify why.
>> >
>> > *_Please Vote:_*
>> >
>> > * *+1 (optionX)*
>> > * *-1 (optionX)*
>> >
>> > And add rationale. _Y_*_ou can vote for a few options._*
>> > If we get enough votes to reach a consensus on one option we'll
>> move to the stage of figuring out the shipping vehicle.
>> >
>> > ***
>> >
>> > *Introduction **(from the paper)**:*
>> > |std::istream::ignore(n, delim)| has surprising behaviour
>> if |delim| is a |char| with a negative value. We can remove the surprise
>> and make code more robust.
>> >
>> > ***
>> >
>> >
>> > *Weekly reviews improve quality!*
>> > Running weekly reviews allows more iterations on each proposal,
>> which
>> > hopefully, in turn, will result in more accurate and subtle fixes.
>> >
>> > Thank you for taking the time to review the proposal, and have a
>> great week!
>> >
>> >
>> > Best Regards,
>> > Inbal Levi
>> >
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> > *Lead Software Engineer @ Millennium*
>> > Isocpp, Boost &"Hamakor" Non-Profits Board Member
>> > ISO C++ LEWG Chair & Israeli NB Chair
>> > C++Now Program Chair & CoreC++ Conference Organizer
>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >
>> >
>> > _______________________________________________
>> > Lib-Ext mailing list
>> > Lib-Ext_at_[hidden]
>> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
>> > Link to this post: http://lists.isocpp.org/lib-ext/2024/05/27378.php
>>
>