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.

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
>