Jump to page: 1 2 3
Thread overview
Unexpectedly nice case of auto return type
Dec 03, 2019
Basile B.
Dec 03, 2019
Basile B.
Dec 03, 2019
Andrea Fontana
Dec 03, 2019
Basile B.
Dec 03, 2019
Basile B.
Dec 03, 2019
Andrea Fontana
Dec 03, 2019
mipri
Dec 03, 2019
mipri
Dec 04, 2019
Adam D. Ruppe
Dec 04, 2019
H. S. Teoh
Dec 04, 2019
Adam D. Ruppe
Dec 04, 2019
Basile B.
Dec 06, 2019
Basile B.
Dec 04, 2019
Basile B.
Dec 03, 2019
Jonathan M Davis
Dec 03, 2019
Basile B.
Dec 03, 2019
Mike Parker
Dec 03, 2019
Mike Parker
Dec 06, 2019
Johannes Loher
Dec 07, 2019
mipri
Dec 03, 2019
Jonathan M Davis
Dec 03, 2019
Basile B.
Dec 03, 2019
Jonathan M Davis
Dec 04, 2019
Basile B.
Dec 03, 2019
H. S. Teoh
Dec 03, 2019
Paul Backus
Dec 03, 2019
H. S. Teoh
Dec 03, 2019
Meta
Dec 03, 2019
Meta
December 03, 2019
I wish something like this was possible, until I change the return type of `alwaysReturnNull` from `void*` to `auto`.


---
class A {}
class B {}

auto alwaysReturnNull() // void*, don't compile
{
    writeln();
    return null;
}

A testA()
{
    return alwaysReturnNull();
}

B testB()
{
    return alwaysReturnNull();
}

void main()
{
    assert( testA() is null );
    assert( testB() is null );
}
---

OMG, isn't it nice that this works ?

I think that this illustrates an non intuitive behavior of auto return types.
One would rather expect auto to work depending on the inner return type.
December 03, 2019
On Tuesday, 3 December 2019 at 07:12:18 UTC, Basile B. wrote:
> I wish something like this was possible, until I change the return type of `alwaysReturnNull` from `void*` to `auto`.
>
>
> ---
> class A {}
> class B {}
>
> auto alwaysReturnNull() // void*, don't compile
> {
>     writeln();
>     return null;
> }
>
> A testA()
> {
>     return alwaysReturnNull();
> }
>
> B testB()
> {
>     return alwaysReturnNull();
> }
>
> void main()
> {
>     assert( testA() is null );
>     assert( testB() is null );
> }
> ---
>
> OMG, isn't it nice that this works ?
>
> I think that this illustrates an non intuitive behavior of auto return types.
> One would rather expect auto to work depending on the inner return type.

Actually I think this can work because of a Tnull (internal compiler type) inference which can always implictly be converted to the static return type (A or B, or even int*):

    auto alwaysReturnNull()// `auto` is translated to Tnull by inference because of `return null`

then:

    A testA()
    {
        return alwaysReturnNull(); // Tnull can be implictly converted to A
    }

still nice tho.
December 03, 2019
On Tuesday, 3 December 2019 at 07:24:31 UTC, Basile B. wrote:
>
>     A testA()
>     {
>         return alwaysReturnNull(); // Tnull can be implictly converted to A
>     }
>
> still nice tho.

Why not [1]?

[1] typeof(null) alwaysReturnNull() { ... }

Andrea
December 03, 2019
On Tuesday, 3 December 2019 at 08:47:45 UTC, Andrea Fontana wrote:
> On Tuesday, 3 December 2019 at 07:24:31 UTC, Basile B. wrote:
>>
>>     A testA()
>>     {
>>         return alwaysReturnNull(); // Tnull can be implictly converted to A
>>     }
>>
>> still nice tho.
>
> Why not [1]?
>
> [1] typeof(null) alwaysReturnNull() { ... }
>
> Andrea

Yeah nice, that works instead of auto.

That reminds me of the discussion about TBottom.
December 03, 2019
On Tuesday, 3 December 2019 at 09:44:20 UTC, Basile B. wrote:
> On Tuesday, 3 December 2019 at 08:47:45 UTC, Andrea Fontana wrote:
>> On Tuesday, 3 December 2019 at 07:24:31 UTC, Basile B. wrote:
>>>
>>>     A testA()
>>>     {
>>>         return alwaysReturnNull(); // Tnull can be implictly converted to A
>>>     }
>>>
>>> still nice tho.
>>
>> Why not [1]?
>>
>> [1] typeof(null) alwaysReturnNull() { ... }
>>
>> Andrea
>
> Yeah nice, that works instead of auto.
>
> That reminds me of the discussion about TBottom.

You see what surprises me here is that we cannot express the special type that is `TypeNull` and that can only have one value (`null`) so instead we have to use `auto` or `typeof(null)`.

Making this type public would make the logic more clear: when `null` is used it's not a value but rather a value of a type that is convertible to all pointers or reference types.
December 03, 2019
On Tuesday, December 3, 2019 12:12:18 AM MST Basile B. via Digitalmars-d- learn wrote:
> I wish something like this was possible, until I change the return type of `alwaysReturnNull` from `void*` to `auto`.
>
>
> ---
> class A {}
> class B {}
>
> auto alwaysReturnNull() // void*, don't compile
> {
>      writeln();
>      return null;
> }
>
> A testA()
> {
>      return alwaysReturnNull();
> }
>
> B testB()
> {
>      return alwaysReturnNull();
> }
>
> void main()
> {
>      assert( testA() is null );
>      assert( testB() is null );
> }
> ---
>
> OMG, isn't it nice that this works ?
>
> I think that this illustrates an non intuitive behavior of auto
> return types.
> One would rather expect auto to work depending on the inner
> return type.

The void* version doesn't work, because void* doesn't implicitly convert to a class type. It has nothing to do with null. auto works thanks to the fact that typeof(null) was added to the language a while back, and since class references can be null, typeof(null) implicitly converts to the class type. Before typeof(null) was added to the language, null by itself had no type, since it's just a literal representing the null value for any pointer or class reference. The result was that using null in generic code or with auto could run into issues. typeof(null) was added to solve those problems.

- Jonathan M Davis



December 03, 2019
On Tuesday, 3 December 2019 at 09:48:39 UTC, Basile B. wrote:
> You see what surprises me here is that we cannot express the special type that is `TypeNull` and that can only have one value (`null`) so instead we have to use `auto` or `typeof(null)`.

You can still create an alias anyway :)

alias TypeNull = typeof(null);



December 03, 2019
On Tuesday, 3 December 2019 at 09:58:36 UTC, Jonathan M Davis wrote:
> On Tuesday, December 3, 2019 12:12:18 AM MST Basile B. via Digitalmars-d- learn wrote:
>> I wish something like this was possible, until I change the return type of `alwaysReturnNull` from `void*` to `auto`.
>>
>>
>> ---
>> class A {}
>> class B {}
>>
>> auto alwaysReturnNull() // void*, don't compile
>> {
>>      writeln();
>>      return null;
>> }
>>
>> A testA()
>> {
>>      return alwaysReturnNull();
>> }
>>
>> B testB()
>> {
>>      return alwaysReturnNull();
>> }
>>
>> void main()
>> {
>>      assert( testA() is null );
>>      assert( testB() is null );
>> }
>> ---
>>
>> OMG, isn't it nice that this works ?
>>
>> I think that this illustrates an non intuitive behavior of auto
>> return types.
>> One would rather expect auto to work depending on the inner
>> return type.
>
> The void* version doesn't work, because void* doesn't implicitly convert to a class type. It has nothing to do with null. auto works thanks to the fact that typeof(null) was added to the language a while back, and since class references can be null, typeof(null) implicitly converts to the class type. Before typeof(null) was added to the language, null by itself had no type, since it's just a literal representing the null value for any pointer or class reference. The result was that using null in generic code or with auto could run into issues. typeof(null) was added to solve those problems.
>
> - Jonathan M Davis

That's interesting details of D developement. Since you reply to the first message I think you have not followed but in the last reply I told that maybe we should be able to name the type of null. I think this relates to TBottom too a bit.
December 03, 2019
On Tuesday, 3 December 2019 at 10:03:22 UTC, Basile B. wrote:

>
> That's interesting details of D developement. Since you reply to the first message I think you have not followed but in the last reply I told that maybe we should be able to name the type of null. I think this relates to TBottom too a bit.

https://github.com/dlang/DIPs/blob/40352337053998885fbd0fe2718c300a322d3996/DIPs/DIP1NNN-DK.md
December 03, 2019
On Tuesday, 3 December 2019 at 10:06:22 UTC, Mike Parker wrote:
> On Tuesday, 3 December 2019 at 10:03:22 UTC, Basile B. wrote:
>
>>
>> That's interesting details of D developement. Since you reply to the first message I think you have not followed but in the last reply I told that maybe we should be able to name the type of null. I think this relates to TBottom too a bit.
>
> https://github.com/dlang/DIPs/blob/40352337053998885fbd0fe2718c300a322d3996/DIPs/DIP1NNN-DK.md

Ah, well. I meant to post the link to the PR:

https://github.com/dlang/DIPs/pull/172
« First   ‹ Prev
1 2 3