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) {...}
}

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

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

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

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

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

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

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

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.

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!