My question is, why D hasn't got an explicit Keyword to check at compile time for non null references?
I understand that such check when they're implicit and refer to all objects they slow down the programm, but why doesn't exist an explicit keyword like @ref or a simple '@' before the Object name or value.
Right now it's very annoying because i get a cryptical error message "Access violation" without any further informations and I have to debug. Only that way I can find where the Null references would access and then, why _and_ where the null references came from. That sucks.
I hate it and so i write in every method to avoid null references "assert(obj !is null);". Now i get an assertion if obj is null and also the file and line. 50% less work then before.
But it's still a runtime error and explicit work which can easily be checked by the compiler at compile time. Then i know: "oh there are null references and there shouldn't be any". So what are the reasons against a special keyword to let the compiler check for non references? I didn't understood it. I heard similar regressions from C# and Java, so why didn't D made it better and did implement something for that?

Some variants I have already seen: const Foo @obj, const @Foo obj or my favourite: const @ref Foo obj.

Greetz

We can do not null in the library reasonably
well. I have a basic one in github:

https://github.com/D-Programming-Language/phobos/pull/477

On Saturday, 21 April 2012 at 22:18:02 UTC, Adam D. Ruppe wrote:
> We can do not null in the library reasonably
> well. I have a basic one in github:
>
> https://github.com/D-Programming-Language/phobos/pull/477

So every time i want to avoid null references i have to write "NotNull!(Foo) f" (or better, because it's a struct: "ref NotNull!(Foo) f")? And therefore i must initialize them with NotNull!(Foo) f = new Foo();? That would be a little annoying. What if i needed in function bar only Foo f which can be null but in quatz i need a not null Reference?
In my opinion the best way would be to initialize them with Foo f = new Foo(); and if i pass them to bar, it will be implicit cast to NotNull!(Foo). I think, that would be the best idea.
The only thing that disturbing me, is, that it is a struct and therefore it passes by value instead as reference and that it is more to write as just "@" or "@ref".

On 04/21/2012 11:40 PM, Namespace wrote:
> My question is, why D hasn't got an explicit Keyword to check at compile
> time for non null references?

It shouldn't be a special keyword. If the compiler can do the necessary analysis to actually enforce that the reference cannot hold a null reference, then it should be the default. Most references are not null.

> I understand that such check when they're implicit and refer to all
> objects they slow down the programm,

How would such a check slow down the program? The rest of your post seems to indicate that you want a compile time check.

> but why doesn't exist an explicit
> keyword like @ref or a simple '@' before the Object name or value.
> Right now it's very annoying because i get a cryptical error message
> "Access violation" without any further informations and I have to debug.
> Only that way I can find where the Null references would access and
> then, why _and_ where the null references came from. That sucks.
> I hate it and so i write in every method to avoid null references
> "assert(obj !is null);". Now i get an assertion if obj is null and also
> the file and line. 50% less work then before.
> But it's still a runtime error and explicit work which can easily be
> checked by the compiler at compile time.

'Easily' would be an oversimplification. There are distinct issues to be solved by the type system, mostly surrounding initialisation.

> Then i know: "oh there are null
> references and there shouldn't be any". So what are the reasons against
> a special keyword to let the compiler check for non references?

There are seldom reasons _against_ a language feature. To make it in, there must be reasons to adapt it. And even more importantly, there must be a good design that integrates well with the rest of the language.
Having a non-null type system would certainly be desirable, but it would be a breaking language change if it was actually designed to be useful.

> I didn't understood it. I heard similar regressions from C# and Java,

In what way would that be a regression?

> so why didn't D made it better and did implement something for that?
>
> Some variants I have already seen: const Foo @obj, const @Foo obj or my
> favourite: const @ref Foo obj.
>
> Greetz

Well, that is the grammar of the feature, but you have not described how it should work. (Saying that the compiler should emit an error for null references does not cut it.)

On 04/22/2012 12:48 AM, Namespace wrote:
> On Saturday, 21 April 2012 at 22:18:02 UTC, Adam D. Ruppe wrote:
>> We can do not null in the library reasonably
>> well. I have a basic one in github:
>>
>> https://github.com/D-Programming-Language/phobos/pull/477
>
> So every time i want to avoid null references i have to write
> "NotNull!(Foo) f" (or better, because it's a struct: "ref NotNull!(Foo)
> f")? And therefore i must initialize them with NotNull!(Foo) f = new
> Foo();? That would be a little annoying. What if i needed in function
> bar only Foo f which can be null but in quatz i need a not null Reference?
> In my opinion the best way would be to initialize them with Foo f = new
> Foo(); and if i pass them to bar, it will be implicit cast to
> NotNull!(Foo).

But this implies a runtime check.

> I think, that would be the best idea.
> The only thing that disturbing me, is, that it is a struct and therefore
> it passes by value instead as reference

You might have a wrong mental model of how classes and structs work in D.

A class reference is much like a struct of the following form:

struct ClassRef{
    ClassImpl* impl;
}


> and that it is more to write as
> just "@" or "@ref".

And only the trivial cases are catched during compilation.

On Saturday, 21 April 2012 at 22:48:27 UTC, Namespace wrote:
> So every time i want to avoid null references i have to write "NotNull!(Foo) f" (or better, because it's a struct: "ref NotNull!(Foo) f")?

It is already a reference! Otherwise, it couldn't be null anyway.

But, yes, you'd write NotNull!Foo. If "NotNull" is too
long for you, you could always alias it to something else.

alias NotNull n;

n!Foo f;

whatever floats your boat.

> And therefore i must initialize them with NotNull!(Foo) f = new Foo();? That would be a little annoying.

If you don't initialize it, it would be null... so yes,
you have to initialize it.

> What if i needed in function bar only Foo f which can be null but in quatz i need a not null Reference?

If it can be null, you check for null or assume it isn't and
just pass it straight to NotNull.

One of the pull request comments suggests adding assumeNotNull
and checkNotNull to help with this. I'll add that later.

> In my opinion the best way would be to initialize them with Foo f = new Foo(); and if i pass them to bar, it will be implicit cast to NotNull!(Foo).

An implicit cast to not null would defeat the point of
the new type!

It implicitly casts to the regular (nullable) type,
but going from null to not null implicitly means you
have no help in catching it from the type system.

I see you're right. Great! But it is only on git hub and not in the standard typecons header in 2.059, right?

Adam D. Ruppe:
> We can do not null in the library reasonably
> well. I have a basic one in github:
>
> https://github.com/D-Programming-Language/phobos/pull/477

It says:

>I haven't actually used any NotNull in practice, but from the attached tests, it looks like it will work well - hence, the pull request.<

I think before putting something in Phobos it's generally better to have used it in Real Code for some time.

I am not sure a mostly-library-defined solution (mostly because @disable is a built-in) is good enough compared to a solution built in the type system.

I will try to use your NotNull struct.

Bye,
bearophile

On Saturday, 21 April 2012 at 23:18:40 UTC, Namespace wrote:
> I see you're right. Great! But it is only on git hub and not in the standard typecons header in 2.059, right?

But one thing: i missed there an invariant which check if t is null.
If i write "f.t = null;" no error occured.

On Saturday, 21 April 2012 at 23:18:40 UTC, Namespace wrote:
> I see you're right. Great! But it is only on git hub and not in the standard typecons header in 2.059, right?

Right, I missed the deadline for that.