Custom Blocks

KennyTM~ kennytm at gmail.com
Thu Aug 12 04:43:25 PDT 2010


On Aug 12, 10 10:25, Robert Jacques wrote:
> On Wed, 11 Aug 2010 17:54:35 -0400, Tomek Sowiński <just at 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.


More information about the Digitalmars-d mailing list