default random object?

[Yigal Chripun]

Andrei Alexandrescu wrote:
> Yigal Chripun wrote:
>> Andrei Alexandrescu wrote:
>>> bearophile wrote:
>>>> random() => floating point [0, 1)
>>>> randInt(a=0, b) => integral [a, b]
>>>> randRange(a=0, b) => integral [a, b)
>>>> uniform(a, b) => floating point [a, b)
>>>> normal(a, b) => good quality normally-distributed number with given
>>>> std dev and avg.
>>>
>>> Leaving normal() aside (does your implementation implement the ziggurat
>>> algorithm? If so, would you agree to contribute it to phobos?), I don't
>>> see how having to memorize four names instead of one is necessarily
>>> awesome and beautiful. Besides uniform() renders "random" redundant.
>>> Hardly a pinnacle of good API design, see realloc() which essentially
>>> makes malloc() and free() redundant.
>>>
>>> Andrei
>>
>> your example counters your claim.
>> The same reason we prefer to use D with so many concepts and keywords
>> over something like brainf**k that is turing-complete with just 8 or
>> so commands can be apllied here.
>> sure, the *implementation* of realloc() makes the *implementations* of
>> free() and malloc() redundunt but it's easier to remember to use
>> free() when you actually want to free something. if free() wasn't
>> available, the first thing I'd do was to use a macro to define it.
>
> My point was that realloc() is wrong, not free(). The sorely missing
> allocation primitive is expand(), and we've been paying for it through
> the nose for decades.
>
> Andrei

I see.
Having 3 functions: malloc(), expand() and free() is indeed a very good 
design.

regarding the original topic, I still generally prefer bearophile's API,
random may be omitted and other small changes are also possible but it 
looks better to me than using something like:
uniform!("[]")(rng, a, b);
maybe some aliases are in order?