On Wednesday, November 23, 2016 15:29:14 Kagamin via Digitalmars-d wrote:
> On Wednesday, 23 November 2016 at 14:30:53 UTC, Andrei
>
> Alexandrescu wrote:
> > This claim would apply to all ranges. There seems to be
> > evidence it is unfounded.
> >
> > The main argument for using the range interface for RNGs is
> > reuse of abstraction. Minute implementation matters are much
> > less important. The main counter-argument is that the
> > abstraction is not fitting well and another abstraction (such
> > as opCall) is more advantageous.
>
> Consider this okayish looking code:
> consume(rng());
> consume(rng.take(2)); //reuses previous value
> consume(rng()); //discards unused value
In the cases where I don't really need a range of random numbers, I've
typically ended up doing stuff like
auto nextNum = rndGen().popFront(), rndGen().front;
though I think that using the comma operator like that is deprecated now.
Adding a helper function such as
auto getNext(R)(ref R range)
if(isInputRange!R)
{
range.popFront();
return range.front;
}
would solve that problem. And there are plenty of cases where having a range
of random numbers is extremely useful. After having dealt with, std.random,
it would really suck to have to deal with a random number generator that was
not range-based. std.random has problems such as not using reference types
for its ranges, but using the range API in the way it does is extremely
useful.
- Jonathan M Davis
