Re: Custom Blocks

[KennyTM~]

On Aug 12, 10 23:42, Robert Jacques wrote:

On Thu, 12 Aug 2010 07:43:25 -0400, KennyTM~ <kenn...@gmail.com> wrote:

On Aug 12, 10 10:25, Robert Jacques wrote:

On Wed, 11 Aug 2010 17:54:35 -0400, Tomek Sowiński <j...@ask.me> wrote:

Robert Jacques napisał:

I was thinking something like this:

void fun(int x, int y, int z, delegate void(int, int, int) dg)

fun(x, y, z, a, b, c) { body }

|
V

fun(x, y, z, (a, b, c) { body });

Mixing function args with delegate args makes me think of foreach:

fun(x, y, z, (a, b, c) { body }); <=> fun(a, b, c; x, y, z) { body }

All great, but if there's no remedy for the return WTF, I'd leave this
(nice) feature in the drawer.

void foo() {
fun(a, b, c; x, y, z) {
return; // who returns?
}
}


Tomek

Fun does. This is the same as function/delegate literals today.
Of course, putting a return statement inside a foreach block is probably
a buggy edge case right now; sometimes it causes the parent scope to
return and sometimes it doesn't compile.

This is an unacceptable buggy edge case. Consider the already-working
code

int find_three(int[] arr) {
foreach (i, x; arr) {
if (x == 3)
return i;
}
return -1;
}

If I replace the foreach with a custom block e.g.

int find_three_retro(int[] arr) {
foreach_retro (i, x; arr) {
if (x == 3)
return i;
}
return -1;
}

then suddenly the function doesn't work anymore. It's better not to
provide a feature inconsistent with other parts of the language.

Code that exploits a bug in the implementation isn't "working" in any
sense of the word. One of the points I was making is that return
statements inside a foreach do different things depending on what you're
foreaching over. So this feature would be adding consistency, not
removing it.

void locate_three_or_five(int[] arr) {
   int res = -1;
   foreach (i, x; arr) {
      if_is_one_of(x, [3, 5]) {
         res = i;
         break;     // now what?
      }
   }
   writeln("found 3 or 5 at ", res);
}