Dear Arthur

Thank you for the feedback. I did not know of view::shuffle and it seems to
do what I want in most cases. However it probably needs to modify the input
range to generate the output and I think one can get around that
restriction.
I assumed this was the right avenue to discuss possible proposals, which is
what I had intended, not just proposing specific extensions. I might be on
the wrong mailing list then.
In any case I will be back with a reference implementation and a technical
description, I have no experience how to write a proposal for std however.

Thanks again, you were very helpful,
Wolfgang Brehm

Am Fr., 8. Nov. 2019 um 00:44 Uhr schrieb Arthur O'Dwyer <
arthur.j.odwyer_at_[hidden]>:

> On Thu, Nov 7, 2019 at 7:11 AM Wolfgang Brehm via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> I recently found std::sample and thought it would be nice to have to have
>> an analogous sample view which samples from a population without repetition
>> - with repetition is so trivial that we can ignore it for now.
>>
>> What do you think about a sample view that accepts a range and a random
>> generator and returns a range which can be iterated over to access the
>> elements of the input range in a random order evaluating a bijective
>> (perfect and minimal) hash function to generate random indices without
>> repetition?
>>
>
> IIUC, what you're describing is a "shuffle_view", not a "sample_view" —
> but you could generate a random sample by piping it into
> ranges::views::take(k). Is that right?
>
> std::vector<int> inputs {3,1,4,1,5,9,2,6,5};
> std::mt19937 g;
> std::vector<int> three_random_digits = std::move(inputs) |
> my::shuffle_view(g) | ranges::views::take(3) | ranges::to<std::vector>();
>
>
> I'd be interested what you think and volunteer to write a sample
>> implementation if there is interest - I am using similar ideas in my own
>> code, but you know how it is, it's not pretty.
>>
>
> A reference implementation should *always* precede any effort at
> standardization. The goal of standardization should be *standardization*,
> not *innovation*. We standardize paper sizes and screw head designs for
> interoperability ("portability"); the general notions of "paper" and
> "screws" themselves should precede standardization efforts and should not
> need any push from a standards body to become widespread.
> </rant>
>
> It might be useful to get a reference implementation of your idea up on
> GitHub. Have you looked into contributing it to any popular implementation,
> such as Eric Niebler's Range-v3 <https://github.com/ericniebler/range-v3>
> or Jonathan Boccara's Pipes <https://github.com/joboccara/pipes>? (If
> you're aiming to get it into std::ranges, Range-v3 would be the relevant
> target. However, prematurely tying yourself to std::ranges might be as bad
> for innovation as prematurely tying yourself to iostreams or std::pmr.)
>
> HTH,
> –Arthur
>