Return values from auto function

Andrey Zherikov andrey.zherikov at gmail.com
Sat Nov 7 12:02:12 UTC 2020


On Saturday, 7 November 2020 at 01:50:15 UTC, Jesse Phillips 
wrote:
> On Friday, 6 November 2020 at 15:06:18 UTC, Andrey Zherikov 
> wrote:
>> 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.
>
> I'm curious what your semantics would be.
>
> # Result!void => Result!int
>
> How does the type know it can convert to int, or string, or Foo?
>
> What does it mean for a void to be an int?
>
> # Result!int => Result!void
>
> If you have something, what does it mean to go to not having 
> that something. Would you really want to implicitly lose that 
> something?

Ideally error type shouldn't depend on what type the operation 
returns but language has a limitation that function must return 
single type.

Technically Failure struct can be moved out from Result(T) but 
the issue remains the same: how to convert Failure to Result!T 
for any T.


More information about the Digitalmars-d-learn mailing list