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




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.


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




 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.


 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


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