Experimental approach to reference-type random number generators

[Dmitry Olshansky]

24-Aug-2013 22:48, Joseph Rushton Wakeling пишет:
> On 24/08/13 20:35, Joseph Rushton Wakeling wrote:
>> I do have one specific query
>
> Actually, two.  Lines 448-457 of the second codepad paste have this
> unittest, with the last line commented out:
>
>
>      // Check .save works
>      foreach (Type; TypeTuple!(MinstdRand0, MinstdRand))
>      {
>          auto rnd1 = Type(unpredictableSeed);
>          auto rnd2 = rnd1.save;
>          //assert(rnd1 == rnd2);
>          // Enable next test when RNGs are reference types
>          version(none) { assert(rnd1 !is rnd2); }
>          //assert(rnd1.take(100).array() == rnd2.take(100).array());
>      }
>
> If the last assert is uncommented,
>
>      assert(rnd1.take(100).array() == rnd2.take(100).array());
>
> ... then running the unittests results in the following error:
>
>      /opt/dmd/include/d2/std/array.d(37): Error: variable
> std.array.array!(Take!(RandomGenerator!(LinearCongruentialEngine!(uint,
> 16807, 0, 2147483647)))).array.r has scoped destruction, cannot build
> closure

Now I'm in the same boat in the midst of wrok of applying new std.uni 
facilities to std.regex. As soon as std.array.array started using 
trusted lambda internally it doesn't accept any range with destructor.

This is simply not acceptable, I'll put a minimized test-case in 
Bugzilla if nobody beats me to it.

>
> This is rather worrying and I'm concerned that this could be a
> fundamental flaw in the whole design.  Can anyone advise on how to fix it?

It seems a fundamental bug in closures. They have to work somehow with 
these structs esp as in this case there need not to allocate GC closure 
(no references escapes scope of std.array.array).

-- 
Dmitry Olshansky