I have auto function 'f' that might return either an error (with some text) or a result (with some value). The problem is that the type of the error is not the same as the type of result so compilation fails.

Here is my code:
----------
struct Result(T)
{
    struct Success
    {
        static if(!is(T == void))
        {
            T value;
        }
    }
    struct Failure
    {
        string error;
    }

    Algebraic!(Success, Failure) result;

    this(Success value)
    {
        result = value;
    }
    this(Failure value)
    {
        result = value;
    }
}
auto success(T)(T value)
{
    return Result!T(Result!T.Success(value));
}
auto failure(string error)
{
    return Result!void(Result!void.Failure(error));
}

auto f(int i)
{
    return i > 0 ? success(i) : failure("err text"); // Error: incompatible types for (success(i)) : (failure("err text")): Result!int and Result!void
}
-----------------

I can make it work if I add a type to `failure` function but this remove brevity in usage:
-----------------
auto failure(T)(string error)
{
    return Result!T(Result!T.Failure(error));
}
auto f(int i)
{
    return i > 0 ? success(i) : failure!int("err text");     // no error
}
-----------------

How can I make the original code compilable without templatizing `failure` function?

On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote:
> I can make it work if I add a type to `failure` function but this remove brevity in usage:
> -----------------
> auto failure(T)(string error)
> {
>     return Result!T(Result!T.Failure(error));
> }
> auto f(int i)
> {
>     return i > 0 ? success(i) : failure!int("err text");     // no error
> }
> -----------------
>
> How can I make the original code compilable without templatizing `failure` function?

You can't. Both return values have to have the same type, which means the failure function has to be able to return more than one type, which means it has to be a template.

On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote:
> On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote:
>>
>> How can I make the original code compilable without templatizing `failure` function?
>
> You can't. Both return values have to have the same type, which means the failure function has to be able to return more than one type, which means it has to be a template.

Being pedantic, he can, by templatising 'f' instead.

On Friday, 6 November 2020 at 13:59:58 UTC, gbram wrote:
> On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote:
>> On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote:
>>>
>>> How can I make the original code compilable without templatizing `failure` function?
>>
>> You can't. Both return values have to have the same type, which means the failure function has to be able to return more than one type, which means it has to be a template.
>
> Being pedantic, he can, by templatising 'f' instead.

Could you share how?

On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote:
> You can't. Both return values have to have the same type, which means the failure function has to be able to return more than one type, which means it has to be a template.

This issue seems hit the inability to implicitly convert custom types. May be it makes more sense to ask in a separate thread.

On Friday, 6 November 2020 at 14:20:40 UTC, Andrey Zherikov wrote:
> On Friday, 6 November 2020 at 12:03:01 UTC, Paul Backus wrote:
>> You can't. Both return values have to have the same type, which means the failure function has to be able to return more than one type, which means it has to be a template.
>
> This issue seems hit the inability to implicitly convert custom types. May be it makes more sense to ask in a separate thread.

The return type must be the same for all execution paths.

Result!void is a different type from Result!int. You aren't passing a 'Result' because that doesn't exist as a type.

Hopefully one of these captures a misunderstanding.

On Friday, 6 November 2020 at 14:58:40 UTC, Jesse Phillips wrote:
> On Friday, 6 November 2020 at 14:20:40 UTC, Andrey Zherikov wrote:
>> This issue seems hit the inability to implicitly convert custom types. May be it makes more sense to ask in a separate thread.
>
> The return type must be the same for all execution paths.
>
> Result!void is a different type from Result!int. You aren't passing a 'Result' because that doesn't exist as a type.

To clarify my statement:
Yes, Result!void and Result!int are different types but I couldn't find a way to implicitly convert one to another.

On Friday, 6 November 2020 at 15:06:18 UTC, Andrey Zherikov wrote:

> To clarify my statement:
> Yes, Result!void and Result!int are different types but I couldn't find a way to implicitly convert one to another.

You can't. Structs do not implicitly convert to each other, templated or otherwise.

On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote:
> I have auto function 'f' that might return either an error (with some text) or a result (with some value). The problem is that the type of the error is not the same as the type of result so compilation fails.
>
> [...]

Sounds like Andrei's "Expected". Here is an implementation for d. https://github.com/tchaloupka/expected

On Friday, 6 November 2020 at 20:05:36 UTC, Ferhat Kurtulmuş wrote:
> On Friday, 6 November 2020 at 10:51:20 UTC, Andrey Zherikov wrote:
>> I have auto function 'f' that might return either an error (with some text) or a result (with some value). The problem is that the type of the error is not the same as the type of result so compilation fails.
>>
>> [...]
>
> Sounds like Andrei's "Expected". Here is an implementation for d. https://github.com/tchaloupka/expected

Hmmm, I wonder how that is different from the idea of 'option'