Azure-functions-host: Investigate support for return value bindings

[mathewc]

Investigate whether we can simplify function signatures in cases where there is only a single ouput binding. Currently we require an output parameter. In such cases, it would be more natural to simply map the single output binding to the return value of the function.

Note that we already support this as a special case for HttpTrigger. We should investigate whether we can generalize that. In function.json since return values aren't named in function signatures, we'd have to use a special name like "$return" or something. We also need to think through what this means for script languages like BAT where there is no "return value" for the function.

This would require core SDK changes to support return value attribute binding. E.g.:

[return: Blob("test", FileAccess.Write)]
public static string Test(
    [QueueTrigger("test")] string message)
{
    return "Testing";
}

[bleroy]

I think the concern is to be as idiomatic as possible for each language. I can't speak for BAT, but for C#, ideally return values would be just that.

Here is a specific example and what I'd expect to write as a user of AF:

Current DocumentDB binding:

public static void Run(string myQueueItem, out object document, TraceWriter log)

What I would expect:

public async static Task<object> Run(string myQueueItem, TraceWriter log)

Or, if I have no good reason to be async:

public static object Run(string myQueueItem, TraceWriter log)

Even for common multiple output bindings, returning a structure would feel less awkward, until AF is using C# 7, at which point returning a tuple will become the best solution.

[bleroy]

Here's another from https://azure.microsoft.com/en-us/documentation/articles/functions-create-an-event-processing-function/

public static void Run(TimerInfo myTimer, out string outputQueueItem, TraceWriter log)

ideally would be:

public static string Run(TimerInfo myTimer, TraceWriter log)

or Task<string> if necessary.

[cartermp]

Yay! Mapping the output parameter to the output of the actual function would be amazing. That would allow for more idiomatic F# as well.

Something like this:

type Item = { Id: string }

// Eeek, byrefs!
let Run(blob: string, output: byref<Item>) =
    let item = { Id = "Some ID" }
    output <- item

Could then turn into this:

type Item = { Id: string }

// Hooray!  The return value is just what returns from the Azure Function!
let Run (blob: string) =
    { Id = "Some ID" }

Or, if explicit typing is needed:

type Item = { Id: string }

let Run (blob: string): Item =
    { Id = "Some ID" }

[fabiocav]

We have _limited_ support for this already (i.e. the http output binding has the ability to process return values, so you don't have to specify a binding parameter), but it would indeed be nice to expand this to other bindings.
As mentioned above, the multiple binding scenario is where things get a little tricky, but we do have some options.

@bleroy I'm also looking forward to C# 7 in AF (for a few reasons :) ). Returning tuples will indeed make this pretty clean.

[mathewc]

FYI: I'm prototyping this now. Basically I'm thinking we can just handle a "$return" output binding specially in our function generation. We map it to normal SDK "out" binding, and simply copy the return value into that out binding after invoking the users function. Meaning we wouldn't actually have to add this to core SDK, where I don't think there is much demand for it anyways.

[mathewc]

Guys, take a look at the PR for this referenced above. You can see some example functions in the samples/tests.