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