Default Executable Member Return Expressions

[TheFanatr]

Default Return Expressions

This proposal describes hypothetical syntax for defining a default return value for an executable member (method, property getter, returning delegate, returning lambda-expression) which has control flows that do not return a value. The use case for this would be not having to write a return statement for control flows with a common outcome, and only having to deal with special cases.

The default value does not have to be a constant, rather it has access to whatever state is initially available to the method, as well as any scope-escaping variables such as is expressions that define variables being used in if statements. If the executable member's body is able to be asynchronous and is marked as such, the await keyword may also be used.

Example

DataContainer CollectData(State state, bool condition) = DataContainer.Create(state.Parameters, null, user ?? User.None)
{
    if (state.Authenticated)
    {
        if (condition)
        {
            return GetData(state.Parameters);
        }
        else if (state.KeepOld)
        {
            var newData = state.OldData.Merge(GetData(state.Parameters));
            newData.Sort();
            return newData;
         }
         return; // returns default value
    }
    else if (state.Valid && state.Identity == Identity.Anonymous)
    {
         if (GetRealIdentity(state))
             return; // returns default value
         else
             return state.GetNewData();
    }
    else if (state.AuthenticationBypassed || state.User is { } user)
        return; // returns default value
    throw new InvalidOperationException();
}

The example isn't intended to be logically cohesive, but rather to showcase the use of the suggested feature. Allowing control flow to exit the body of the method would also cause the default value to be returned.

For property get statements, the feature would be used as follows.

bool Property
{
    set => SetProperty(value);
    get = false
    {
        /* ... */
    }
}

For lambda expressions, the feature would be used as follows.

async () = await GetDataAsync() => /* ... */

[svick]

What would be the point of doing this?

It seems to me that the only point is that it would occasionally made code shorter. But this feature would not be useful that often and it would make the code less clear: when you see return;, you wouldn't be able to immediately tell what exactly does it mean. For these reasons, I think this feature would not be worth it.

[TheFanatr]

I see your point about it being unclear when the empty return statement is used, but due to the fact that value-returning methods usually have return statements with values, I believe that having an empty one by contrast signals that some different behaviour is being triggered, so I don’t see that too much as being a major concern. A different keyword could also be used but I’m not sure what would fit best; maybe yield? I would also argue that such a feature would be useful quite frequently, as this suggestion arose from my personal realization that such a feature would prove useful in many areas of my own projects. The example I have provided in the original post was arbitrary, and I basically just created circumstances in which the hypothetical features could be used; I believe that in the real world it would be much more obviously useful. Even if that is incorrect, I still say that having it as a convenient feature would be nice for when it is useful.

[HaloFour]

You can already accomplish this behavior quite easily by declaring a temporary variable with the default value at the start of the method:

DataContainer CollectData(State state, bool condition) {
    val df = DataContainer.Create(state.Parameters, null, user ?? User.None);
    if (state.Authenticated)
    {
        if (condition)
        {
            return GetData(state.Parameters);
        }
        else if (state.KeepOld)
        {
            var newData = state.OldData.Merge(GetData(state.Parameters));
            newData.Sort();
            return newData;
         }
         return; // returns default value
    }
    else if (state.Valid && state.Identity == Identity.Anonymous)
    {
         if (GetRealIdentity(state))
             return df; // returns default value
         else
             return state.GetNewData();
    }
    else if (state.AuthenticationBypassed || state.User is { } user)
        return df; // returns default value
    throw new InvalidOperationException();
}

I think this is much clearer than having some implicit value that would be returned when you use a return statement that otherwise appears to return no value. There's also the question as to when that default value actually gets returned and the state of any values that are captured in that expression. What if state is mutated, or completely reassigned? It's not easy to intuit what should happen there. So even assuming that the default value is created lazily it's not at all clear how the value should be created.

[yaakov-h]

@HaloFour I think you missed a spot on line 15.

[canton7]

To take your specific example, you can refactor this method to avoid multiple returns easily, which also avoids the issue:

DataContainer CollectData(State state, bool condition)
{
    var result = DataContainer.Create(state.Parameters, null, user ?? User.None);
    if (state.Authenticated)
    {
        if (condition)
        {
            result = GetData(state.Parameters);
        }
        else if (state.KeepOld)
        {
            var newData = state.OldData.Merge(GetData(state.Parameters));
            newData.Sort();
            result = newData;
        }
    }
    else if (state.Valid && state.Identity == Identity.Anonymous)
    {
         if (!GetRealIdentity(state))
             result = state.GetNewData();
    }
    else if (state.AuthenticationBypassed || state.User is { } user)
    {
        // Nothing to do - use default
    }
    else
    {
        throw new InvalidOperationException();
    }

    return result;
}

[DavidArno]

I appreciate that you say that you example isn't intended to be logically cohesive, but if we treat it as such, then there's a lot of noise (the else's specifically as they aren't needed) that can be removed and a default can easily be supplied via a local function. We then end up with:

    DataContainer CollectData(State state, bool condition)
    {
        if (state.Authenticated)
        {
            if (condition) return GetData(state.Parameters);
            if (state.KeepOld) return state.OldData.Merge(GetData(state.Parameters)).Sort();
            return Default();
        }

        if (state.Valid && state.Identity == Identity.Anonymous)
             return GetRealIdentity(state) ? Default() : state.GetNewData();

        if (state.AuthenticationBypassed) return Default();
        
        if (state.User is {} user) return DataContainer.Create(state.Parameters, null, user);

        throw new InvalidOperationException();
        
        DataContainer Default() 
            => DataContainer.Create(state.Parameters, null, User.None);
    }

Adding new syntax to replace that local function would cost a lot of time and effort and would further complicate the language. It's really hard to see how that could be justified when a local function does the job just as well.