import std.algorithm, std.range;

auto foo(R)(R a, immutable int b)
{
    return a.map!(x => x + b);
}

unittest @nogc @safe
{
    int[] test = [1,2,3];

    assert(test.foo(3).equal(only(4,5,6)));
}

Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map

On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote:
> import std.algorithm, std.range;
>
> auto foo(R)(R a, immutable int b)
> {
>     return a.map!(x => x + b);
> }
>
> unittest @nogc @safe
> {
>     int[] test = [1,2,3];
>
>     assert(test.foo(3).equal(only(4,5,6)));
> }
>
> Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map

import std.algorithm, std.range;

auto foo(R)(R a, immutable int b)
{
    return a.map!(x => x + b);
}

@nogc @safe unittest
{
    int[3] test = [1,2,3];

    assert(test[].foo(3).equal(only(4,5,6)));
}

does this count?

On Sunday, 30 August 2015 at 10:21:20 UTC, rsw0x wrote:
> On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote:
>> import std.algorithm, std.range;
>>
>> auto foo(R)(R a, immutable int b)
>> {
>>     return a.map!(x => x + b);
>> }
>>
>> unittest @nogc @safe
>> {
>>     int[] test = [1,2,3];
>>
>>     assert(test.foo(3).equal(only(4,5,6)));
>> }
>>
>> Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map
>
> import std.algorithm, std.range;
>
> auto foo(R)(R a, immutable int b)
> {
>     return a.map!(x => x + b);
> }
>
> @nogc @safe unittest
> {
>     int[3] test = [1,2,3];
>
>     assert(test[].foo(3).equal(only(4,5,6)));
> }
>
> does this count?

Oh, I think I see what you were asking. It doesn't compile with LDC, but it compiles just fine with latest DMD.
hmm

On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote:
> import std.algorithm, std.range;
>
> auto foo(R)(R a, immutable int b)
> {
>     return a.map!(x => x + b);
> }
>
> unittest @nogc @safe
> {
>     int[] test = [1,2,3];
>
>     assert(test.foo(3).equal(only(4,5,6)));
> }
>
> Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map

Ok, so now I feel stupid. Not only was the unittest I gave above broken anyway, I realised what my underlying problem was within minutes of posting...

Carry on, nothing to see here...

On Sun, 2015-08-30 at 10:38 +0000, John Colvin via Digitalmars-d wrote:
> On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote:
> > import std.algorithm, std.range;
> > 
> > auto foo(R)(R a, immutable int b)
> > {
> >     return a.map!(x => x + b);
> > }
> > 
> > unittest @nogc @safe
> > {
> >     int[] test = [1,2,3];
> > 
> >     assert(test.foo(3).equal(only(4,5,6)));
> > }
> > 
> > Challenge: reimplement `foo` such that above unittest will compile. No cheating with malloc etc. Bonus points if you don't have to implement a modified version of std.algorithm.map
> 
> Ok, so now I feel stupid. Not only was the unittest I gave above broken anyway, I realised what my underlying problem was within minutes of posting...

So what was the problem?

> Carry on, nothing to see here...

See above…

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sunday, 30 August 2015 at 11:21:34 UTC, Russel Winder wrote:
> On Sun, 2015-08-30 at 10:38 +0000, John Colvin via Digitalmars-d wrote:
>> On Sunday, 30 August 2015 at 10:15:14 UTC, John Colvin wrote:
>> > [...]
>> 
>> Ok, so now I feel stupid. Not only was the unittest I gave above broken anyway, I realised what my underlying problem was within minutes of posting...
>
> So what was the problem?
>
>> Carry on, nothing to see here...
>
> See above…

https://issues.dlang.org/show_bug.cgi?id=14982 was confusing me.

On Sunday 30 August 2015 12:21, rsw0x wrote:

> import std.algorithm, std.range;
> 
> auto foo(R)(R a, immutable int b)
> {
>      return a.map!(x => x + b);
> }
> 
> @nogc @safe unittest
> {
>      int[3] test = [1,2,3];
> 
>      assert(test[].foo(3).equal(only(4,5,6)));
> }
> 
> does this count?

I think this shouldn't compile and it only does so because of issue 14771.

https://issues.dlang.org/show_bug.cgi?id=14771

The delegate in foo uses a local variable and it's returned from the function, so it needs a closure. Where does the closure go if not on the GC heap?

See also this Learn thread about how to call map with a delegate in a @nogc function:

http://forum.dlang.org/post/kpwbtskhnkkiwkdsfzby@forum.dlang.org

Ali Çehreli's solution there may or may not actually be @nogc, but I'm afraid it relies on issue 14771 any way:

http://forum.dlang.org/post/mqr506$10kf$1@digitalmars.com

On Sunday, 30 August 2015 at 13:36:45 UTC, anonymous wrote:
> On Sunday 30 August 2015 12:21, rsw0x wrote:
>
>> [...]
>
> I think this shouldn't compile and it only does so because of issue 14771.
>
> https://issues.dlang.org/show_bug.cgi?id=14771
>
> The delegate in foo uses a local variable and it's returned from the function, so it needs a closure. Where does the closure go if not on the GC heap?
>
> See also this Learn thread about how to call map with a delegate in a @nogc function:
>
> http://forum.dlang.org/post/kpwbtskhnkkiwkdsfzby@forum.dlang.org
>
> Ali Çehreli's solution there may or may not actually be @nogc, but I'm afraid it relies on issue 14771 any way:
>
> http://forum.dlang.org/post/mqr506$10kf$1@digitalmars.com

Is there any reason that closure in this particular example can't be created on the stack? Seems a bit weird.

On Sunday 30 August 2015 16:43, rsw0x wrote:

> Is there any reason that closure in this particular example can't be created on the stack? Seems a bit weird.

It may be possible to store it on the stack somehow, or as part of the map struct. I don't know.

The point is, that's not what happens. It goes on the GC heap, breaking @nogc.