> 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@gmx.net> wrote:
On 21/05/2024 12.44, Jonathan Wakely via Lib-Ext wrote:
>
>
> On Mon, 20 May 2024 at 19:05, Inbal Levi <sinbal2l@gmail.com <mailto:sinbal2l@gmail.com>> 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@lists.isocpp.org
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/lib-ext
> Link to this post: http://lists.isocpp.org/lib-ext/2024/05/27378.php