Reference semantic ranges and algorithms (and std.random)

[monarch_dodra]

On Tuesday, 18 September 2012 at 17:59:04 UTC, Jonathan M Davis 
wrote:
> On Tuesday, September 18, 2012 17:05:26 monarch_dodra wrote:
>> This is issue #1: I'd propose that all objects in std.random be
>> migrated to classes (or be made reference structs), sooner than
>> later. This might break some code, so I do not know how this is
>> usually done, but I think it is necessary. I do not, however,
>> propose that they should all derive from a base class.
>
> Moving to classes would definitely break code, but it should be 
> possible to
> make them reference types simply by making it so that their 
> internal state is
> in a separate object held by a pointer.

I was thinking of doing that. The problem with this (as I've run 
into and stated in another thread), is a problem of 
initialization: The simpler PRNGs are init'ed seeded, and are 
ready for use immediately. Changing to this approach would break 
the initialization, as shown in this post:

http://forum.dlang.org/thread/bvuquzwfykiytdwsqkky@forum.dlang.org#post-yvtsivozyhqzscgddbrl:40forum.dlang.org

A "used to be valid" PRNG has now become an un-initialized PRNG". 
This is extremely insidious, as the code still compiles, but will 
crash.

I'm hoping my thread goes somewhere, but since I doubt it, I've 
thought up of two other solutions for a "clean" migration:

#1
Keep as struct (as you suggest), but use the opCall hack. I HATE 
this solution.

#2
Change to class, but leave behind some "opCall"s for each old 
constructor, plus an extra one for default:
class A
{
     static A opCall(){return new A();}
     static A opCall(int i){return new A(i);}

     this(){}
     this(int){}

     /// ...
}

void main()
{
     A a1 = A();  //Works AND constructs
     A a2 = A(5); //Still Works
     A a3 = new A();  //Works
     A a4 = new A(5); //Works
}

In this case, I'm fine with having some opCalls, because 
technically, they aren't mixed with the constructors and used as 
hacks: The constructors are all there, and the opCalls, merelly 
forward to them.

That said, they *would* be destined for deprecation.

Use of "A a;" would create a problem though, but nothing's 
perfect...

Is this second solution something you think I should look into?