"return [xxx] if (condition);" one-liner syntax proposal.

[baranacikgoz]

Result pattern/monad is becoming popular day by day. I also have a custom implementation on my projects. We usually can chain methods if we add extension methods to our Result class. But sometimes, we can't always chain methods or we don't want to. For this situations, we have to manually write this kind of flow-control code (it may differ depending on your implementation):

if (result.IsError)
{
    return result.Error;
}

For all this kind of situations (it may not be relevant to result pattern at-all of course), I have a new syntax proposal. It is

return result.Error if (result.IsError);

OR

return if (result.IsError) result.Error;

Here is an example without this one-liner syntax (as we curently don't have):

private static async Task<Result<Response>> AddProductToStore(
        [FromBody] Request request,
        [FromServices] IRepository<Store> storesRepository,
        [FromServices] IRepository<Product> productsRepository,
        [FromKeyedServices(nameof(Inventory))] IUnitOfWork unitOfWork,
        CancellationToken cancellationToken)
    {
        var storeResult = await storesRepository.SingleOrDefaultAsResultAsync(new StoreByIdSpec(request.StoreId), cancellationToken);
        if (storeResult.IsFailure)
        {
            return storeResult.Error!;
        }
        var store = storeResult.Value!;

        var productResult = await productsRepository.SingleOrDefaultAsResultAsync(new ProductByIdSpec(request.ProductId), cancellationToken);
        if (productResult.IsFailure)
        {
            return productResult.Error!;
        }
        var product = productResult.Value!;

        var storeProduct = store.AddProduct(product.Id, request.Quantity, request.Price);

        await unitOfWork.SaveChangesAsync(cancellationToken);

        return new Response(storeProduct.Id);
    }

With new syntax it could become:

private static async Task<Result<Response>> AddProductToStore(
        [FromBody] Request request,
        [FromServices] IRepository<Store> storesRepository,
        [FromServices] IRepository<Product> productsRepository,
        [FromKeyedServices(nameof(Inventory))] IUnitOfWork unitOfWork,
        CancellationToken cancellationToken)
    {
        var storeResult = await storesRepository.SingleOrDefaultAsResultAsync(new StoreByIdSpec(request.StoreId), cancellationToken);
        return storeResult.Error if (storeResult.IsFailure);

        var store = storeResult.Value!;

        var productResult = await productsRepository.SingleOrDefaultAsResultAsync(new ProductByIdSpec(request.ProductId), cancellationToken);
        return productResult.Error if (productResult.IsFailure);

        var product = productResult.Value!;

        var storeProduct = store.AddProduct(product.Id, request.Quantity, request.Price);

        await unitOfWork.SaveChangesAsync(cancellationToken);

        return new Response(storeProduct.Id);
    }

This could increase readability and make language less verbose in such situations.

[HaloFour]

See: #2195

It's already a one-liner:

if (result.IsError) return result.Error;

[baranacikgoz]

Is there a way to bypass "use brackets" rules for this kind of situations? We generally have strict editorconfigs mostly treats warnings as errors

[siegfriedpammer]

I would expect #pragma warning disable ID to work in those cases.

If such a new syntax were added, the people in charge would probably add a new rule that prevents you from using the new syntax. Adding new syntax to work around linter misconfiguration is the wrong approach.

[CyrusNajmabadi]

Is there a way to bypass "use brackets" rules for this kind of situations?

Yes. Disable that rule.

[CyrusNajmabadi]

@siegfriedpammer's positoin is the same as the team's. We don't create new features to workaround a person/team having a particular linter rule in place htat prevents them from using an existing feature. And it's for the reason Siegfried mentioned. We could add that new feature, just to find those same users going: i can't use this either because i've enabled a linter rule to disallow it.

The solution here is simple. Disable that linter rule and use the features that exist to solve this exact case already.

[baranacikgoz]

@siegfriedpammer and @CyrusNajmabadi thanks for the clear answers. I'll search for a solution that allows no brackets for one-liners only

[jnm2]

Since you mentioned monads, I would love to have await generalized to other types and maybe be called yield:

private static async Task<Result<Response>> AddProductToStore(
    [FromBody] Request request,
    [FromServices] IRepository<Store> storesRepository,
    [FromServices] IRepository<Product> productsRepository,
    [FromKeyedServices(nameof(Inventory))] IUnitOfWork unitOfWork,
    CancellationToken cancellationToken)
{
    var store = yield await storesRepository.SingleOrDefaultAsResultAsync(new StoreByIdSpec(request.StoreId), cancellationToken);

    var product = yield await productsRepository.SingleOrDefaultAsResultAsync(new ProductByIdSpec(request.ProductId), cancellationToken);

    var storeProduct = store.AddProduct(product.Id, request.Quantity, request.Price);

    await unitOfWork.SaveChangesAsync(cancellationToken);

    return new Response(storeProduct.Id);
}

void Result<int> M(Result<int> first, Result<int> second)
{
    return (yield first) + (yield second);
}

Would desugar to:

void Result<int> M(Result<int> first, Result<int> second)
{
    if (first.IsFailure) return first.Error;
    var firstValue = first.Value;
    if (second.IsFailure) return second.Error;
    var secondValue = second.Value;
    return firstValue + secondValue;
}

Attributes or a witness struct would have to be used in order to let the compiler know how to generate the pattern given your custom Result<T>.

[baranacikgoz]

That's a really cool idea

[colejohnson66]

So many Pythonic proposals, and they're all rejected:

#2195, #8197, #8125

C# is a C-like language, not a Python-like one.

[huoyaoyuan]

Quoting myself: #7962 (comment)

I put strong down votes about changing the order of conditions like that. It's way too Englism or European-ism.

If the condition is tested first, it should appear at first. This is the nature order that fits execution order.

[ParsaMehdipour]

[jnm2: removed quote of entire post]

Remove the curly braces and put the return statement right next to the the if condition and you got yourself a one-liner syntax

[marchewek]

This could increase readability and make language less verbose in such situations.

I would argue that the problem lies elsewhere - if you used exceptions in the first place, you wouldn't have to validate the return codes... so many years with exceptions and people are still using bool/int/enum return codes... and the argument "this is the API we have to work with" could be countered by "then make your own anti-corruption layer that will encapsulate the external API"...