On Tuesday, 3 December 2019 at 10:19:02 UTC, Jonathan M Davis
wrote:
On Tuesday, December 3, 2019 3:03:22 AM MST Basile B. via
Digitalmars-d- learn wrote:
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.
There isn't much point in giving the type of null an explicit
name given that it doesn't come up very often, and typeof(null)
is quite explicit about what the type is. Also, anyone doing
much generic programming in D is going to be well versed in
typeof. They might not know about typeof(null) explicitly, but
they should recognize what it means when they see it, and if
someone were trying to get the type of null, it would be the
obvious thing to try anyway. And typeof(null) isn't even the
prime case where typeof gets used on something other than an
object. From what I've seen, typeof(return) gets used far more.
As for TBottom, while the DIP does give it a relationship to
null, they're still separate things, and giving typeof(null) a
name wouldn't affect TBottom at all.
- Jonathan M Davis
I think that any internal compiler types that are also things in
code should be named.
Things like tuples are really a thing in the compiler (TupleExp,
TypeTuple, also Tuple in dtemplate.d, ...), we still need a
library type for tuples while everything there in the compiler.
