Use _Invoke_result_t<_Urng&> instead of _Urng::result_type in _Rng_from_urng

[S. B. Tam (cpplearner)]

C++20 uniform_random_bit_generator does not require the presence of member result_type.

This is tested in libc++ tests std/algorithms/alg.modifying.operations/alg.random.shuffle/ranges_shuffle.pass.cpp and std/algorithms/alg.modifying.operations/alg.random.sample/ranges_sample.pass.cpp. Unfortunately they fail even after this change, because they assume that std::array iterators are pointers.

[Stephan T. Lavavej (StephanTLavavej)]

Thanks for finding and fixing this bug! I've pushed a fix for value categories with a corresponding test change (fails without the fix, passes with it).

[Matt Stephanson (MattStephanson)]

C++20 uniform_random_bit_generator does not require the presence of member result_type

That's true for the concept, but doesn't [rand.req.urng]/3 require "G provides a nested typedef-name result_­type that denotes the same type as invoke_­result_­t<G&>"? These generators in libc++ meet the URBG concept, but not the named requirements.

[S. B. Tam (cpplearner)]

C++20 uniform_random_bit_generator does not require the presence of member result_type

That's true for the concept, but doesn't [rand.req.urng]/3 require "G provides a nested typedef-name result_­type that denotes the same type as invoke_­result_­t<G&>"? These generators in libc++ meet the URBG concept, but not the named requirements.

Old std::shuffle requires the generator type to meet the uniform random bit generator named requirements (and thus requires member result_type), but C++20 ranges::shuffle only requires the type to model the concept.

Since ranges::shuffle uses _Rng_from_urng, the latter must not rely on result_type.

If we want to be strict, we could change std::shuffle to check the presence of result_type.

[Matt Stephanson (MattStephanson)]

I see, thanks for explaining.

…

On Aug 7, 2022, at 10:17 PM, S. B. Tam ***@***.***> wrote:  C++20 uniform_random_bit_generator does not require the presence of member result_type That's true for the concept, but doesn't [rand.req.urng]/3 require "G provides a nested typedef-name result_­type that denotes the same type as invoke_­result_­t<G&>"? These generators in libc++ meet the URBG concept, but not the named requirements. Old std::shuffle requires the generator type to meet the uniform random bit generator named requirements (and thus requires member result_type), but C++20 ranges::shuffle only requires the type to model the concept. Since ranges::shuffle uses _Rng_from_urng, the latter must not rely on result_type. If we want to be strict, we could change std::shuffle to check the presence of result_type. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

[Casey Carter (CaseyCarter)]

Isn't _Invoke_result_t<_Urng&> a bit heavyweight when we could simply decltype(_STD declval<_Urng&>()())?

[Stephan T. Lavavej (StephanTLavavej)]

Sure, but I don't think that this will ever be frequently instantiated in a program - so I'm not concerned about throughput here.

[Stephan T. Lavavej (StephanTLavavej)]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[Stephan T. Lavavej (StephanTLavavej)]

Thanks for randomly fixing this bug! 🐞 🛠️ 😹