Proposal: Syntax and compiler support for decorator pattern

[brazilbean]

Note: this is my first time making a proposal here. If I have omitted an important part of this process, please let me know. :)

For this proposal, I use the term decorator to mean a function that modifies the behavior of a provided function by wrapping it in additional behavior. It may return a new function or it may execute the function.

Examples

public void RunWithInt(Action<int> function) 
{
    function(10);
}

public Action<string> WrapWithStringInput(Action<int> function)
{
    return (str) => function(str.Length);
}

Most of my usage for decorators falls in these categories:

• Methods that can fill inputs in lambda argument lists, producing a simpler lambda (i.e. partials)
• Allows for setup and, specifically, teardown code that isn't appropriate for IDisposable (e.g. may throw exceptions)

A real (but simplified) example from work:

public class ComplicatedObjectFactory
{
    public static void RunWithComplicatedObject(Action<ComplicatedObject> function) 
    {
        var complicated = new ComplicatedObject();
        function(complicated);
        complicated.FinisherThatCanThrowExceptions();
    }
}

Problem

These decorator methods imply that the input function is wrapped or executed, but there is no formal contract guaranteeing this is the case. For example:

public void RunWithInt(Action<int> function)
{
    // do nothing
}

In this case, the code compiles, but the intent was violated.

Or, an example showing how the compiler cannot guarantee the input function is executed:

public int DoWork()
{
    int result;  
    RunWithInt((i) => result = i);
    return result; // <- compiler error- use of unassigned local variable result
}

Proposal

I propose syntax indicating that an input function MUST be executed within the scope the method call.

public void RunWithInt(closure Action<int> function) 
{
    function(10);
}

Here, the closure keyword would indicate that the argument must be invoked before the method returns. The logic should be similar to supplying the return value for a method (i.e. must return unless an exception is thrown, etc.).

To support the partial function use case (i.e. filling arguments and returning a function with a smaller argument list), I think we would need an additional keyword that indicates that the return value must be a lambda (method, Action, Func, ...) that guarantees execution of the input function:

public decorator Action<bool> WrapWithInt(closure Action<int,bool> function) 
{
    return (b) => function(10,b);
}

Thus, the compiler would ensure that:

• a closure argument is invoked within the method body
• OR it is passed as a closure to another method
• OR the method is a decorator and the closure is invoked within the body of a locally-declared lambda and that lambda is returned
• OR the method is a decorator and the closure is passed to another decorator and the result is returned
  Also:
• a decorator must be composed using closure inputs

Other considerations

• Would multiple closures be allowed as multiple arguments?
  public void DoStuff(closure Action<int> fun1, closure Action<int> fun2){ ... }

• Can you return an object with the decorated closure as a member variable?
  public decorator Tuple<int, Action> WrapStuff(Action<int> function) { return Tuple.Create(10, () => function(10)); }

• Or do you use the decorator keyword on the return type?
  public Tuple<int, decorated Action> WrapStuff( ... ) { ... }

• What about decorating multiple closures?

  • Probably not supported -> how do you track which input maps to which output?
  • Or does that matter, as long as all decorated outputs were composed from closure inputs?
    public void Wrap(Action<int> fun1, Action<string> fun2, out decorated Action funA, out decorated Action funB) ...

• What about closures as default arguments?

  • Probably not, as you could define null as the default - but how do you guarantee null is invoked?

• What about asynchronous execution?

  • Can you have async decorators?
  • Can an async method have a closure argument?
    • Is it enough to guarantee that once the return Task is complete, the method has been invoked?

Extra credit (syntactic sugar)

With closure syntax in place, you could also support closure argument shorthand.

Current syntax:

public void RunWithInt(Action<int> function, string otherArg = "foobar" ) { ... }

public void DoStuff()
{
    RunWithInt(
    (i) => 
    {
        Console.WriteLine(i);
        OtherMethod(i);
        OtherMethod2(i+2);
    }, "some other arg"); // <- ugly
}

Proposed syntax (a la groovy):

public void DoStuff()
{
    RunWithInt("some other arg") (i) =>
    {
        Console.WriteLine(i);
        OtherMethod(i);
        OtherMethod2(i+2);
    }; 
}

• How do you handle multiple closure inputs with this syntax (if supported)?
• Do you require that the closure argument be the last in the method declaration?
• How do you handle default arguments?
  • Closure(s) can come after defaults?

Note: by allowing closures to come after default arguments (and ensuring no closure can have a default), you could at least ensure that all other arguments are assigned before passing in the lambda:

public void DoStuff()
{
    RunWithInt("some other arg",
    (i) => 
    {
        Console.WriteLine(i);
        OtherMethod(i);
        OtherMethod2(i+2);
    }); // <- not as ugly - at this point just an extra ')'
}

[HaloFour]

These decorator methods imply that the input function is wrapped or executed, but there is no formal contract guaranteeing this is the case.

Why must there be any formal contract? It's not that uncommon for a decorator to bypass the implementation for what it has wrapped, e.g. a caching/memoizing decorator.

If this behavior is something that you want to enforce within your projects I would suggest writing an analyzer.

[bondsbw]

decorator and closure are opt-in for the method and its parameters. Is there any guarantee at the call site?

I don't see any visual distinction. Reading the call site code, I wouldn't know whether these guarantees are in place or not.

[jnm2]

If this behavior is something that you want to enforce within your projects I would suggest writing an analyzer.

Given the frequency that I hear this, we need to rename this repo csharp-analyzer-idea-generator. 😛