default random object?

[Andrei Alexandrescu]

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