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



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
>