• John Colvin (13/13) Aug 30 2015 import std.algorithm, std.range;
• rsw0x (12/25) Aug 30 2015 import std.algorithm, std.range;
• rsw0x (4/33) Aug 30 2015 Oh, I think I see what you were asking. It doesn't compile with
• anonymous (12/27) Aug 30 2015 I think this shouldn't compile and it only does so because of issue 1477...
• rsw0x (3/17) Aug 30 2015 Is there any reason that closure in this particular example can't
• anonymous (5/7) Aug 30 2015 It may be possible to store it on the stack somehow, or as part of the m...
• John Colvin (5/18) Aug 30 2015 Ok, so now I feel stupid. Not only was the unittest I gave above
• Russel Winder via Digitalmars-d (9/32) Aug 30 2015 See above…
• John Colvin (2/13) Aug 30 2015 https://issues.dlang.org/show_bug.cgi?id=14982 was confusing me.

"John Colvin" <john.loughran.colvin gmail.com> writes:

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

"rsw0x" <anonymous anonymous.com> writes:

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?

"rsw0x" <anonymous anonymous.com> writes:

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

anonymous <anonymous example.com> writes:

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

"rsw0x" <anonymous anonymous.com> writes:

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.

anonymous <anonymous example.com> writes:

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.

"John Colvin" <john.loughran.colvin gmail.com> writes:

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...

Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:

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

"John Colvin" <john.loughran.colvin gmail.com> writes:

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.