On Fri, 4 Apr 2025 at 10:56, Jonathan Wakely <jwak...@redhat.com> wrote: > > On Fri, 4 Apr 2025 at 10:32, Tomasz Kaminski <tkami...@redhat.com> wrote: > > > > > > > > On Fri, Apr 4, 2025 at 11:10 AM Jonathan Wakely <jwak...@redhat.com> wrote: > >> > >> In r15-8980-gf4b6acfc36fb1f I introduced a new function object for > >> finding the smaller of two distances. In bugzilla Hewill Kang pointed > >> out that we still need to explicitly convert the result back to the > >> right difference type, because the result might be an integer-like class > >> type that doesn't convert to an integral type explicitly. > >> > >> Rather than doing that conversion in the __mindist function object, I > >> think it's simpler to remove it again and just do a comparison and > >> assignment. We always want the result to have a specific type, so we can > >> just check if the value of the other type is smaller, and then convert > >> that to the other type if so. > >> > >> libstdc++-v3/ChangeLog: > >> > >> PR libstdc++/101587 > >> * include/bits/ranges_uninitialized.h (__detail::__mindist): > >> Remove. > >> (ranges::uninitialized_copy, ranges::uninitialized_copy_n) > >> (ranges::uninitialized_move, ranges::uninitialized_move_n): Use > >> comparison and assignment instead of __mindist. > >> --- > >> > >> Tested x86_64-linux. > > > > The revert makes sense, but this integer-like-classes are causing a lot of > > churm. > > I would like to see some tests for this scenario in algorithms tests. > > Using iota<__int128>(0, 5) is good way to produce integer-like difference > > type, > > that is sized. (iota<__int128>(0) | views::take(5)) creates not-sized one. > > Yes, but our integer-like class type (__max_size_type) is implicitly > convertible to integer types, so is more user-friendly than required > by the standard. I don't think we want to change that, but it means > it's easy to miss places where portable code should really be using an > explicit conversion.
I suppose we could add a test_awkward_range type to the testsuite which uses a different integer-like class type which doesn't have implicit conversions. User code isn't allowed to define its own integer-like class types, but we could do it for the purposes of the testsuite. But as I said ... we don't actually need to make libstdc++ perform those conversions explicitly, because the only difference types we support are built-in integers and __max_diff_type, and they all convert implicitly. > Actually I'm not sure this patch is even needed ... because the only > integer-like class type that is allowed is the one provided by the > library ... and we don't need the explicit conversion for our type. > But I like the simplification anyway. > > Anyway, I'll add some more tests using iota_view, but they were > already passing before this patch, that's why I didn't bother.
