[Bug libstdc++/114477] New: The user-defined constructor of filter_view::iterator is not fully compliant with the standard

[Bug libstdc++/114477] New: The user-defined constructor of filter_view::iterator is not fully compliant with the standard

[hewillk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477

            Bug ID: 114477
           Summary: The user-defined constructor of filter_view::iterator
                    is not fully compliant with the standard
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hewillk at gmail dot com
  Target Milestone: ---

Since P3059R0 is closed (although I feel bad about this), this suggests that
libstdc++ may need to modify the user-defined constructor of
filter_view::iterator:

  #include <ranges>
  auto base = std::views::iota(0);
  auto filter = base | std::views::filter([](int) { return true; });
  auto begin = decltype(filter.begin())(filter, base.begin()); // should ok

https://godbolt.org/z/T7nY68rej

[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477

Jiang An <de34 at live dot cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |de34 at live dot cn

--- Comment #1 from Jiang An <de34 at live dot cn> ---
Constructors of the following types seemly need to be changed:

basic_istream_view::_Iterator
filter_view::_Iterator
filter_view::_Sentinel
transform_view::_Iterator
join_view::_Sentinel
lazy_split_view::_OuterIter
split_view::_Iterator
split_view::_Sentinel

Currently libstdc++'s versions take pointers to the base views, while the
standard requires to take references.

[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to 康桓瑋 from comment #0)
>   auto begin = decltype(filter.begin())(filter, base.begin()); // should ok

I have very little motivation to "fix" this. Nobody should be writing code like
that anyway.

[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=97600
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
FWIW these ctors were originally changed to take view* instead of view& with
r11-4584 to work around the unstable satisfaction issue PR97600#c1, and then
with r11-5954 we implemented an optimization in the frontend to avoid
considering non-class conversion operators when computing a conversion to a
class type (IIRC), which made the workaround redundant.

So I guess we can remove this workaround and make these ctors take view& again.
 But I don't feel totally confident that there isn't an IFNDR issue in this
standard formulation that only GCC was able to detect (before the
optimization)...

[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Changing them seems like a bad idea.

Maybe we could keep the pointer constructors for internal use (possibly making
them private and adding friend decls as needed) and *also* add the ones taking
references, so pedantic conformance (but never use those ourselves).

But I think it would be safer to just do nothing, since I don't think this has
ever caused a real problem in real code.

[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard

[de34 at live dot cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477

--- Comment #5 from Jiang An <de34 at live dot cn> ---
(In reply to 康桓瑋 from comment #0)
> Since P3059R0 is closed (although I feel bad about this)

BTW, now I think this is somehow unfortunate.
P3059 behaved like a follow-up paper of P2711 IMO. Both papers effectively
suggested that "some design choices of C++23 views are better, let's apply them
to C++20 views".

[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard

[hewillk at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477

--- Comment #6 from 康桓瑋 <hewillk at gmail dot com> ---
(In reply to Jiang An from comment #5)
> (In reply to 康桓瑋 from comment #0)
> > Since P3059R0 is closed (although I feel bad about this)
> 
> BTW, now I think this is somehow unfortunate.
> P3059 behaved like a follow-up paper of P2711 IMO. Both papers effectively
> suggested that "some design choices of C++23 views are better, let's apply
> them to C++20 views".

You are absolutely right. Is there any way to reopen it? I recall that it was
just because the committee didn't want to spend time on it.

[Bug libstdc++/114477] The user-defined constructor of filter_view::iterator is not fully compliant with the standard

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The notes say it was closed because you didn't want to work on it.

https://github.com/cplusplus/papers/issues/1726#issuecomment-2014094319

It sounds like the Ranges study group supported the direction. If you want to
pursue it, just submit a revised paper. I think it would be sufficient to
expand the discussion of the libstdc++ implementation to point out that it
can't break GCC users because those constructors don't exist anyway. The MSVC
implementation should be inspected, and advice from MSVC STL maintainers
sought, to determine the impact on their users. Does range-v3 provide those
constructors? What about other third-party ranges libraries?