Re: [Vala] Why do regular reference types leak null?

[Sam Danielson <samdanielson gmail com>]

2009/8/14 Jiří Zárevúcky <zarevucky jiri gmail com>:
> On 08/14/2009 10:57 PM, Sam Danielson wrote:
> > Perhaps I am misunderstanding the purpose of nullable types. The Vala
> > tutorial explains, "By default, Vala will make sure that all reference
> > point to actual objects." As I understand, the whole point of Foo? is
> > so that we can have nulls without infecting Foo with a null variant.
>
> That section is wrong. (Who the hell wrote that?)
>
> It only applies to method arguments and return values, not variables. Any
> variable of a reference type can be null, regardless of how it is defined.
> According to juergbi, it has always been that way, and it will not change in
> the near future (the analysis is way too complicated,

Hmm. Juerg added the --enable-non-null-experimental option and
separated out the experimental null checks in April. This would not
make sense as a deprecation scheme because loosening the type system
by simply deleting non-nullability would not break existing code.

> I personally don't see the need anyway).

If Vala is just a gobject C generator then you're right since there
are no non-nullable pointers in C. The runtime checks are useful in
that regard and runtime checks of function arguments should definitely
be part of a library's public interface. But within Vala it would make
more sense to statically enforce non-nullability since the complexity
of the type system and its syntax has already been penalized to
accommodate those checks. What, specifically, is too complicated about
the analysis? Perhaps I am being naive.

-Sam Danielson