Language proposal: DSL-like method invokes and custom code blocks wrappers

[Opiumtm]

Allow with keyword to be used to invoke methods in lock-like or using-like manner.

Such method should have first argument of delegate type with no parameters and possible return value.

Any other named delegate arguments are treated as optional additional wrapped code blocks with the same name as argument. If additional block is absent at invoke site, then null is passed for argument value.

Optional wrapped blocks are invoked with on keyword at call-site.

Arguments of any other types are used as regular arguments for invoke. If there are none non-delegate arguments, then () at with or on blocks could be omitted.

Examples:

// Example 1 - custom wrapper with regular parameter
public static void readLock(Action c, ReaderWriterLockSlim l)
{
   l.EnterReadLock(); 
   try
   {
       c();
   }
   finally
   {
       l.ExitReadLock();
   }
}

// usages

var rl = new ReaderWriterLockSlim();

with readLock(rl) {
     // code inside wrapped code block is translated to 
     // implicit lambda function to pass as first delegate argument
    Console.WriteLine("!!!");
}
// same as:
readLock(() => { Console.WriteLine("!!!"); }, rl);
// this is also allowed as curved braces are optional.
with readlock(rl) Console.WriteLine("!!!");

// Example 2 - custom wrapper with optional code blocks
public static void guard(Action c, Action<Exception> fail, Action always)
{
    try
    {
        c();
    }
    catch (Exception e)
    {
        if (fail != null)
        {
            fail(e);
        }
    }
    finally
    {
        if (always != null)
        {
            always();
        }
    }
}

// usages

with guard
{
    Console.WriteLine("!!!");
}
// same as:
guard(() => Console.WriteLine("!!!"), null, null);

with guard
{
    Console.WriteLine("!!!");
    throw new Exception("let's crush");
}
on always
{
    Console.WriteLine("always invoked");
}
on fail(e)
{
    Console.WriteLine("epic fail " + e.Message);
}
// same as:
guard(() => {
    Console.WriteLine("!!!");
    throw new Exception("let's crush");   
}, e => {
    Console.WriteLine("epic fail " + e.Message);
}, () => {
    Console.WriteLine("always invoked");
});

// Example 3 - value-returning custom wrapper

public static async T doAwait<T>(Func<Task<T>> c)
{
    return await c();
}

// usages
Task<int> task = SomeService.GetTask();

int result = with doAwait task;
// same as 
int result = doAwait(() => task);

// Example 4 - collection processing

public static IEnumerable<T> doProcess<T>(Func<IEnumerable<T>> src, Func<T, bool> filter, Comparison<T> compare)
{
   IEnumerable<T> generate()
   {
      foreach (var a in src)
      {
          if (filter == null || filter(a))
          {
              yield return a;
          }
      }
   }

   if (compare == null)
   {
       return generate();
   }

   var r = new List<T>();
   foreach (var a in generate())
   {
       r.Add(a);
   }
   r.Sort(compare);
   return r;
}

// usage

var arr = new int[] { 10, 5, 4, 12, 11, 3, 6, 2 };

with doProcess arr
on filter(a) a < 10
on compare(a, b) a.CompareTo(b)
// same as
doProcess(() => arr, a => a < 10, (a, b) => a.CompareTo(b));

Motivation

More clean and DSL-like callback invokes when it's apply and when lambda syntax is clumsy and unnatural - especially when there are many named optional delegate arguments and it's very unhelpful to use stream of positional arguments to pass lambda-functions.

[HaloFour]

How do you propose to handle control statements within the translated lambdas?

public string M() {
    with readLock(rl) {
        // do something
        return "foo";
    }
}

[HaloFour]

Also, in the same vein as #1151

[Opiumtm]

@HaloFour
If delegate argument "returns" void, then it's simple to generate code that supports return from enclosing function.

public string M() {
    with readLock(rl) {
        // do something
        return "foo";
    }
}

would be translated to

public string M() {
    string __return_slot_1 = default(string);
    bool __is_return_1 = false;
    readLock(() => {
       // do something       
       __return_slot_1 = "foo";
       __is_return_1 = true;
       return;
    }, rl);
    if (__is_return_1)
    {
        return __return_slot_1;
    }
}

[HaloFour]

IMHO that could get quite janky and there would likely be scenarios that are ambiguous. For example, in your guard example you're using throw to indicate a failed assertion that the guard method is expected to handle and then behave on. But if the compiler were rewriting control statements to reexecute them outside of the receiver it would then rethrow after guard returned, which might not be what you want it to do.

[Opiumtm]

@HaloFour
for any ambiguous and greatly non-intuitive behavior, standard lambda-function behavior should take precedence.

if the compiler were rewriting control statements to reexecute them outside of the receiver it would then rethrow after guard returned

It shouldn't. Compiler shouldn't automatically rethrow any exception from the wrapped code block.
Wrapper method could not catch any exception from delegate invoke to pass it outside of method or wrapper method itself can simply rethrow exception if needed. If it catch exception then it's intended behavior by wrapper method developer to suppress exceptions.

[jnm2]

Isn't this issue almost the same as #85?

[Opiumtm]

@jnm2 My proposal is somewhat extended to support optional named wrapped blocks.

[jnm2]

Ah, I see.

on error()
{
    continue;
}

❔ 😄

[Opiumtm]

@jnm2 all control statements could be easily propagated by exploiting lambda's closures to pass information out of lambda and then check it later.

on error()
{
    continue;
}

could be translated to something like

bool __cstatement_flag_1 = false;

customGuard(() => {
  // do something
}, () => {
  // here is "on error" lambda
  __cstatement_flag_1 = true;
  return;
});
if (__cstatement_flag_1)
{
    continue;
}

[theunrepentantgeek]

Very similar in intent to my proposal for block parameters (#589), though with different syntax.

[quinmars]

I prefer your proposed sytax over #1151. What I don't like is the asymetry in the parenthesised parameters.

    with readLock(x)

here x is a direct argument to readLock and not to the associated action, whereas

   on fail(x)

is an argument to the action.
Anyway, I think there are several challanges to solve to fully integrate this feature to the C# language. In my opinion it must support method returns, yield returns and awaits. This is, however, a much bigger undertaking than a simple lambda transformation.

This should be possible:

    with guard
    {
        yield return something;
    }

and

    with guard
    {
        var x = await something;
    }

and

    static void doTwice(Action a)
    {
        a();
        a();
    }

    var i = 0;
    with doTwice
    {
        i++;
        return i;  // the function should return 1 and not 2
    }

If one of these example is not possible, it's better to stick with simple lambdas, IMHO.

[Opiumtm]

@quinmars
All could be possible except yield return ... (there is no technical way to implement yield return for outer method in lambda)

Anyway, currently it's almost unreadable when method have several delegate arguments (it's common in functional-heavy code) and you try to support delegate arguments with lambdas.

[dmitriyse]

Probably it's related to the new proposal: #3025

[vladd]

I wonder if Ruby-style proc would solve the original problem.