std.random2

[Dmitry Olshansky]

09-Jan-2013 00:38, H. S. Teoh пишет:
> On Tue, Jan 08, 2013 at 07:46:46PM +0100, Joseph Rushton Wakeling wrote:
>> On 01/08/2013 07:38 PM, ixid wrote:
>>> I imagine there has been some detailed discussion of the std.nameX
>>> idea of libraries so forgive me if this has been discussed.
>>
>> I appreciate your concern on this point, but I don't think it's the
>> right thing to focus on in this specific discussion.
>>
>> What I really want address is: how do we get the design of std.random
>> _right_?
>>
>> How we go about incorporating that new design into Phobos with
>> minimal hassle for users is a different issue and one we can face
>> when the time comes.
>
> For one thing, I'd say definitely make RNGs have reference semantics.
> Passing by value just doesn't make sense; for large generators it
> consumes too much stack space and risks stack overflow, and in any case
> copying RNGs unintentionally causes duplicated sequences, which is very
> bad.
>
> For those cases where you *want* to copy an RNG, it should be made into
> a forward range and then you use .save explicitly.
>
> I wonder if it even makes sense to force RNGs to inherit from a common
> base class, so that reference semantics are enforced even for
> user-defined types. But this may be a bit too heavy-handed (and it will
> alienate the no-GC crowd).

I'd push a well working (from my POV) design of polymorphic adapters. 
The idea is that wrapping is doable but buing the speed back is unsolved 
problem. BTW there is one for input ranges - InputRangeObject.

Then each generator/distribution defines specific structs and there is 
one templated polymorphic wrapper that has a common base class.

IMO this gives the best of both worlds (this is how std.digest was 
designed) at no implementation cost.

The no-GC, performance and "just give me this one little PRGN" needs are 
served with specific structs.

Then polymorphic behavior with hot-swappable PRNG, "I'm coming from 
Java/Ruby/..." etc. needs are served with a wrapper + base class or 
interface. It may even give a per struct aliases of the respective 
wrapper to be more user-friendly.


-- 
Dmitry Olshansky