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