Tap seems limited since you cannot halt execution on failure

[benprime]

Tap is very useful in that you can use it to return the passed in result and do multiple operations on a single result object. For example.

return getMyResult()
    .Tap(x => DoWork1(x))
    .Tap(x => DoWork2(x))
    .Tap(x => DoWork3(x));

However, sometimes you would like to return the result and still depend on whether the DoWork() method failed. If you could assume that Funcs passed to DoWork all returned the same result type as the "parent" result, that would be useful.

I find myself writing extensions methods like the following:

public static async Task<Result<T>> Tap<T>(this Task<Result<T>> resultTask, Func<T, Task<Result<T>>> func)
{
	var result = await resultTask.ConfigureAwait(Result.DefaultConfigureAwait);
	if (!result.IsSuccess) return result;
	var tapResult = await func(result.Value).ConfigureAwait(Result.DefaultConfigureAwait);
	return tapResult.IsFailure
		? tapResult
		: result;
}

In this case, the flow would be identical, except that execution would stop when a tap Func returns a failed result.

What is the reasoning behind having the result of a Tap operation be ignored in the railway flow?

[vkhorikov]

You should be able to use Bind for this. Tap is only for when you want to ignore the result entirely.

The reason for the separation between Bind and Tap (previously, they all were overloads of OnSuccess) is to separate OnSuccess due to it becoming too bloated.

[benprime]

I have not come up against many scenarios where I'd want to ignore the result completely, but I have come up against several scenarios where I would like to run an operation, check the result as normal, but return the original result rather than the new result.

Unless I'm missing some context, using bind for this would amount to this code, correct?

return getMyResult()
    .Bind(x => {
        var result = DoWork1(x);
        if (result.IsSuccess) return Result.Success(x);
        return result;
    })
    .Bind(x => {
        var result = DoWork2(x);
        if (result.IsSuccess) return Result.Success(x);
        return result;
    })
    .Bind(x =>
    {
        var result = DoWork3(x);
        if (result.IsSuccess) return Result.Success(x);
        return result;
    });

This works, but the developers that I work with (and myself) usually end up writing extension methods like TapAndCheck that feel like they should be core to the library.

[space-alien]

I do it this way:

return GetCustomer()
    .Bind(customer => UpdateCustomer(customer)
        .Map(_ => customer))
    .Bind(customer => DoWork(customer)
        .Map(() => customer));

UpdateCustomer() returns a Result containing a value that we aren't interested in.
DoWork() returns a Result with no value.

[benprime]

Thank you. We'll use .Bind as outlined here.

[space-alien]

@vkhorikov Do you think there is any case for adding a new method for this?

[vkhorikov]

Yeah, we should add this to the library. TapAndCheck (@benprime's suggestion) sounds appropriate to me.

[benprime]

@vkhorikov Would you like me to create a PR?

[vkhorikov]

Please do.

[space-alien]

Consider whether it would be safer and more intuitive if we added Tap() overloads for Func<Result> that bind the inner result success/failure while ignoring its return value?

See also #174

[benprime]

Addressed as part of PR #192