www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Q: Why only int return values in opApply?

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter, is there a technical reason why you can only return int's from 
an opApply()?  It would be nice to be able to define other types:

class Foo {};
class Bar {};

class Baz {
   Bar[] array;
   Foo opApply(Foo delegate(inout Bar) dg) {...}
}
May 24 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:c8u1ke$13bo$1 digitaldaemon.com...
 Walter, is there a technical reason why you can only return int's from
 an opApply()?  It would be nice to be able to define other types:

 class Foo {};
 class Bar {};

 class Baz {
    Bar[] array;
    Foo opApply(Foo delegate(inout Bar) dg) {...}
 }

User code never sees the return value and cannot access the return value from opApply(). It's a 'magic' value known only to the compiler generated glue code for foreach.
May 24 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c8u69i$1fr8$2 digitaldaemon.com...
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:c8u1ke$13bo$1 digitaldaemon.com...
 Walter, is there a technical reason why you can only return int's from
 an opApply()?  It would be nice to be able to define other types:

 class Foo {};
 class Bar {};

 class Baz {
    Bar[] array;
    Foo opApply(Foo delegate(inout Bar) dg) {...}
 }

User code never sees the return value and cannot access the return value from opApply(). It's a 'magic' value known only to the compiler generated glue code for foreach.

And I repeat my longstanding request that it not return int, but rather return an enum having only one public value, say, for expository purposes only, "OK". The implementer of opApply() may return only OK, or the non-OK value returned from the delegate. In this way it's nice and safe, and interferes not one whit with the current mechanism. If we stay as we are, people _will_ inevitably write bad opApply()s.
May 25 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 "Walter" <newshound digitalmars.com> wrote in message
 User code never sees the return value and cannot access the return value
 from opApply(). It's a 'magic' value known only to the compiler


 glue code for foreach.

And I repeat my longstanding request that it not return int, but rather

 enum having only one public value, say, for expository purposes only,

 implementer of opApply() may return only OK, or the non-OK value returned

 the delegate. In this way it's nice and safe, and interferes not one whit

 the current mechanism. If we stay as we are, people _will_ inevitably

 opApply()s.

I suppose I've always been more comfortable working under the hood with numeric literals rather than putting a layer of dressing over them.
May 25 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:c90u2g$123$2 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 "Walter" <newshound digitalmars.com> wrote in message
 User code never sees the return value and cannot access the return value
 from opApply(). It's a 'magic' value known only to the compiler


 glue code for foreach.

And I repeat my longstanding request that it not return int, but rather

 enum having only one public value, say, for expository purposes only,

 implementer of opApply() may return only OK, or the non-OK value returned

 the delegate. In this way it's nice and safe, and interferes not one whit

 the current mechanism. If we stay as we are, people _will_ inevitably

 opApply()s.

I suppose I've always been more comfortable working under the hood with numeric literals rather than putting a layer of dressing over them.

Sure, but they're not entirely under the hood, are they? Some of the wires are showing, so I'm just asking that you cover them in insulation.
May 25 2004
parent Juan C <Juan_member pathlink.com> writes:
Sure, but they're not entirely under the hood, are they? Some of the wires are
showing, so I'm just asking that you cover them in insulation.

I'm sure the lawyers would prefer you to post a "Danger: high voltage!" sign instead. B-)
May 25 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
class Foo {};
class Bar {};

class Baz {
   Bar[] array;
   Foo opApply(Foo delegate(inout Bar) dg) {...}
}

User code never sees the return value and cannot access the return value from opApply(). It's a 'magic' value known only to the compiler generated glue code for foreach.

What happens if you include a return statement in the foreach? Baz baz = ....; foreach(Bar bar; baz) { if(condition) return bar; }
May 26 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Walter wrote:
class Foo {};
class Bar {};

class Baz {
   Bar[] array;
   Foo opApply(Foo delegate(inout Bar) dg) {...}
}

User code never sees the return value and cannot access the return value from opApply(). It's a 'magic' value known only to the compiler generated glue code for foreach.

What happens if you include a return statement in the foreach? Baz baz = ....; foreach(Bar bar; baz) { if(condition) return bar; }

return, continue, break, goto - these are all covered by the return value from the compiler-generated delegate passed to the opApply, to which the code at the foreach site responds. Naturally, if you start returning any value other than 0 from the opApply, one of these actions will happen, and your code will do very strange things. This is why I've been after Walter for months to change it from an int to an enum with only one public value. We, the opApply programmers, can return only two things from an opApply() - 0, to indicate successful completion, and the non-0 value returned from the delegate. Anything else is a manifest bug.
May 26 2004
next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
That sounds like a job for a boolean (ahem ...)

 :-)


"Matthew"  wrote
 This is why I've been after Walter for months to change it from an int to

 with only one public value. We, the opApply programmers, can return only

 things from an opApply() - 0, to indicate successful completion, and the

 value returned from the delegate. Anything else is a manifest bug.

May 26 2004
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Matthew wrote:
Walter wrote:

class Foo {};
class Bar {};

class Baz {
  Bar[] array;
  Foo opApply(Foo delegate(inout Bar) dg) {...}
}

User code never sees the return value and cannot access the return value from opApply(). It's a 'magic' value known only to the compiler generated glue code for foreach.

What happens if you include a return statement in the foreach? Baz baz = ....; foreach(Bar bar; baz) { if(condition) return bar; }

return, continue, break, goto - these are all covered by the return value from the compiler-generated delegate passed to the opApply, to which the code at the foreach site responds. Naturally, if you start returning any value other than 0 from the opApply, one of these actions will happen, and your code will do very strange things. This is why I've been after Walter for months to change it from an int to an enum with only one public value. We, the opApply programmers, can return only two things from an opApply() - 0, to indicate successful completion, and the non-0 value returned from the delegate. Anything else is a manifest bug.

Ah, cool. I understand now. Thanks!
May 26 2004