> For that, you have static if contitions, and indeed you can make it a compile-time error.

Can you show me this as code? And are there any plans to realize non-null references or strategies to avoid such things? Otherwise there would really be something important missing in D.

> Yes, you must because whetheer obj is null is only known at runtime.

Yes, but if i forget the assert i get an Access Violation error with no more informations. Problem is nobody knows _why_ he gets this error, because the error message gives no information.
So it must be a better solution then to write in every method "assert(obj_param !is null");". Best of all solutions would be that a special keyword, for example  scope, ensure that lvalues would except but _no_ null-references.

On 04/17/2012 10:37 AM, Namespace wrote:
>> Yes, you must because whetheer obj is null is only known at runtime.
>
> Yes, but if i forget the assert i get an Access Violation error with no
> more informations. Problem is nobody knows _why_ he gets this error,
> because the error message gives no information.

In order to get a meaningful error, the compiler would have to inject code that checked every access through a class reference. Unfortunately that would bring too much overhead and not be acceptable in a system language.

But it could be a part of the non-release builds. I don't have any idea how slow program would become if every class dereferencing would be checked against null like that. (?)

> So it must be a better solution then to write in every method
> "assert(obj_param !is null");".

Not in every method, but only in methods that actually dereference that pointer. Intermediate functions that simply pass the parameter to another function need not check the condition.

In the end, null references are a part of D. The code must be written in a way to accept it.

As an aside, enforce() may be more suitable and a little shorter:

  enforce(obj_param, "Even with a message");

Whether to use assert() or enforce() depends on the function.

> Best of all solutions would be that a
> special keyword, for example scope, ensure that lvalues would except but
> _no_ null-references.

Yes, the keyword would be a little shorter than the assert() or enforce() above but D already has very many keywords. :)

Finally, actually it is possible to have bugs of the same sort even with references in C++:

// C++ code

struct S
{
    int i;

    S(int param_i)
        :
        i(param_i)
    {}
};

S * make_S(int i)
{
    return (i == 42) ? new S(i) : 0;
}

void use_S(const S & s)
{
    int i = s.i;
}

int main()
{
    use_S(*make_S(100));
}

The output is the same as in D:

Segmentation fault

So, as you see, neither C++ provide any help here.

C++'s references have these meanings:

* On the parameter list: "I would like to have a real object please." As seen above, it is so easy to violate that. The caller of use_S() realizes that a reference is needed and just dereferences the pointer at hand. See, the caller must ensure even in C++ that the pointer that is available is not NULL.

* On the return type: "What I give you is an alias to an existing object." Even this is a false promise without tool support, because the reference may be of an automatic local object.

Ali

> > Best of all solutions would be that a
> > special keyword, for example scope, ensure that lvalues would
> except but
> > _no_ null-references.
>
> Yes, the keyword would be a little shorter than the assert() or enforce() above but D already has very many keywords. :)

Yes, but scope is an unused storage keyword, isn't it?
So it could be an idea to avoid speed losses with the current method and ensure that the object is not null, if it's intentional.

On 04/17/2012 08:10 PM, Namespace wrote:
>> > Best of all solutions would be that a
>> > special keyword, for example scope, ensure that lvalues would
>> except but
>> > _no_ null-references.
>>
>> Yes, the keyword would be a little shorter than the assert() or
>> enforce() above but D already has very many keywords. :)
>
> Yes, but scope is an unused storage keyword, isn't it?

It is used.

> So it could be an idea to avoid speed losses with the current method and
> ensure that the object is not null, if it's intentional.

Define 'ensure'.

> Define 'ensure'.

Guarantee, that the given object parameter isn't a null reference.

On 04/17/2012 08:40 PM, Namespace wrote:
>> Define 'ensure'.
>
> Guarantee, that the given object parameter isn't a null reference.

But C++ does not do that either.
Are you asking for a full-blown non-null type system?

> But C++ does not do that either.
> Are you asking for a full-blown non-null type system?

Yes, but of course only with a special Keyword/Storage class.

On 04/17/2012 09:16 PM, Namespace wrote:
>> But C++ does not do that either.
>> Are you asking for a full-blown non-null type system?
>
> Yes, but of course only with a special Keyword/Storage class.

If it is not the default, how would you enforce it at the caller side?

On Tuesday, 17 April 2012 at 19:56:11 UTC, Timon Gehr wrote:
> On 04/17/2012 09:16 PM, Namespace wrote:
>>> But C++ does not do that either.
>>> Are you asking for a full-blown non-null type system?
>>
>> Yes, but of course only with a special Keyword/Storage class.
>
> If it is not the default, how would you enforce it at the caller side?

By the compiler who throws an error message or a warning.
A warning or a better error message would help also, if a null-reference was in use.
But only the message "Access violation" without any information isn't enough, imo.

It seems that not-null references wouldn't be a part of D in near future.