Joseph Rushton Wakeling:

> Anyway, here's my thinking behind the opCall idea.  One of the major shifts of the move to classes is that, suddenly, all of these entities have to be explicitly allocated.

So creating a random number generator can't be @nogc?

Bye,
bearophile

On Sunday, 13 July 2014 at 15:31:51 UTC, bearophile wrote:
> Joseph Rushton Wakeling:
>
>> Anyway, here's my thinking behind the opCall idea.  One of the major shifts of the move to classes is that, suddenly, all of these entities have to be explicitly allocated.
>
> So creating a random number generator can't be @nogc?
>
> Bye,
> bearophile

std.typecons.scoped _should_ still work - I actually suggest adding unit tests for this as it is quite an important use case.

On Sunday, 13 July 2014 at 15:31:51 UTC, bearophile wrote:
> So creating a random number generator can't be @nogc?

I think even as things are there is nothing stopping the user from manually allocating and using "emplace" to create an RNG instance without relying on the GC.  However, even if not, I think this would be less of a problem, as in general things like RNG instances can be expected to be allocated "high up" in the program and passed down into the inner parts where @nogc becomes a concern.

What really matters to me is stuff like Sample and Cover, where we can readily expect that they may be called in inner loops of the program, and so having lots of allocations via "new" would be a big problem.  So, it follows that the current helper functions (sample, cover, etc.) need to be rewritten at some point with this in mind.

It's not a problem I propose to solve for the 1.0.0 release, but it is a problem that needs addressing in the long run.

Out of curiosity, do you have any ideas or suggestions for how to address the requirement for RNGs and related functionality to be reference types, together with the wish to support @nogc ... ?  Preferably in a way that avoids the user having to explicitly indicate destruction?

On Sunday, 13 July 2014 at 15:34:31 UTC, Dicebot wrote:
> std.typecons.scoped _should_ still work - I actually suggest adding unit tests for this as it is quite an important use case.

std.typecons.scoped works per se (I'm adding unittests as we speak) but using my current dmd, this:

    // confirm scoped allocation is @nogc
    void scopedRNG(T)(T seed) @nogc
    {
        auto gen = scoped!UniformRNG(seed);
    }

    scopedRNG(unpredictableSeed);

... fails to compile with the error,

    Error: @nogc function 'hap.random.generator.__unittestL91_27.scopedRNG!uint.scopedRNG' cannot call non-@nogc function 'std.typecons.scoped!(LinearCongruentialEngine!(uint, 16807u, 0u, 2147483647u)).scoped!(uint).scoped'

... even if the constructor of the RNG in question is marked @nogc together with all that it calls.

Is this possibly an issue with 'scoped'?  Was it only quite recently patched to support @nogc?  I'll update my installed compiler if so.

On Sunday, 13 July 2014 at 16:01:11 UTC, Joseph Rushton Wakeling wrote:
> Is this possibly an issue with 'scoped'?  Was it only quite recently patched to support @nogc?  I'll update my installed compiler if so.

Quite likely it has not been updated to @nogc at all - which makes scoped kind of joke if it is true :)

On Sunday, 13 July 2014 at 16:12:16 UTC, Dicebot wrote:
> Quite likely it has not been updated to @nogc at all - which makes scoped kind of joke if it is true :)

Seems to be the case, looking at current scoped() code in Phobos (I just updated my dmd/druntime/phobos install:-)

BTW I note that inside the static struct Scoped you have a private Scoped_store together with a public alias_this.  This would normally clash with https://issues.dlang.org/show_bug.cgi?id=10996 -- I'm guessing the reason it doesn't in this case is because it's all wrapped up in the scoped() template, so that the Scoped struct is actually created in the same module (the same scope even!) as all the places it will actually be used?

Joseph Rushton Wakeling:

> What really matters to me is stuff like Sample and Cover, where we can readily expect that they may be called in inner loops of the program, and so having lots of allocations via "new" would be a big problem.  So, it follows that the current helper functions (sample, cover, etc.) need to be rewritten at some point with this in mind.

I think @nogc is a good improvement for D, despite Walter and other people (and I think Don) were very sceptical about it, because it's like a new lens that allows me to see important things about my code that I wasn't able to see before. Phobos has to be modified in many places to allow both usage patterns for people that want to write short clean code (that allocates automatically and lets the GC free), and performance-conscious people that need to avoid most or all heap allocations. What's unfortunate is that the @nogc attribute was not present for lot of time of development of Phobos, so several Phobos things now need to be modified and some old APIs could give problems. std.random2 should offers ways to be used as much as possible from @nogc code, see below.


> It's not a problem I propose to solve for the 1.0.0 release, but it is a problem that needs addressing in the long run.

Even if the 1.0.0 release of std.random2 is not much @nogc, in my opinion it needs to have an API designed to allow it to be retrofitted cleanly and nicely for @nogc usages too.


> do you have any ideas or suggestions for how to address the requirement for RNGs and related functionality to be reference types, together with the wish to support @nogc ... ?  Preferably in a way that avoids the user having to explicitly indicate destruction?

If you are not using the GC, and you don't want to indicate destruction, you have to use RAII and perhaps RefCounted. You can allocate on the C heap manually, or on the stack, or you can allocate on the stack or C heap using one of Andrei's future allocators.

Bye,
bearophile

On Sunday, 13 July 2014 at 16:20:12 UTC, Joseph Rushton Wakeling wrote:
> I'm guessing the reason it doesn't in this case is because it's all wrapped up in the scoped() template

... no, it's because the private Scoped_store is passed out via the Scoped_payload property.

Anyway, the actual scoped() method itself is templated, so whether it can be @nogc or not obviously depends on its arguments and has to be inferred.  The trouble is with the destructor ~this() which is in no way dependent on template parameters, but in calling the destructor of the scoped payload, depends on the payload's own destructor for whether it can be @nogc or not.

On Sunday, 13 July 2014 at 16:24:29 UTC, bearophile wrote:
> Even if the 1.0.0 release of std.random2 is not much @nogc, in my opinion it needs to have an API designed to allow it to be retrofitted cleanly and nicely for @nogc usages too.

Completely agree.  Incidentally the library is intended for use with dmd 2.065+ which precludes unqualified use of @nogc for now, but that will be addressed after 2.066 is released and ldc/gdc upgrade their frontend/Phobos dependencies.

> If you are not using the GC, and you don't want to indicate destruction, you have to use RAII and perhaps RefCounted. You can allocate on the C heap manually, or on the stack, or you can allocate on the stack or C heap using one of Andrei's future allocators.

Stack allocation is arguably appropriate for stuff like Sample, however, the created entity needs to be able to escape the scope of the helper function which allocates it.

On Sunday, 13 July 2014 at 16:29:11 UTC, Joseph Rushton Wakeling wrote:
> Anyway, the actual scoped() method itself is templated, so whether it can be @nogc or not obviously depends on its arguments and has to be inferred.

Hmm, I tried patching up what I could of the Scoped struct's methods to use @nogc, but to no avail where hap.random is concerned :-(