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

[Jürg Billeter <j bitron ch>]

On Fri, 2009-08-14 at 13:57 -0700, Sam Danielson wrote:
> By cast I mean that there must be some way to get a Foo out of a Foo?.
> When I encounter a Foo? I should (ideally) not be allowed to
> dereference it unless I have first ensured it is not null by
> transforming it into a Foo. Vala is not dependently typed so the
> preceding operation isn't generally supported but I believe that nulls
> are important enough to warrant special handling. The Foo/Foo?
> dichotomy is precisely that special case. The only thing we're missing
> are the static checks to make it usable, IMHO.
>
> Here's what I mean by dependently typed.
>
> // f is Foo?
> if (f != null) {
>   // f is Foo
> }
>
> Of course the conditional would have to be statically verifiable. If
> it is not then f would remain Foo? inside the consequent branch. But
> disallowing dereference for Foo? is perhaps too draconian for Vala
> since the constraint could be enforced elsewhere and making the
> programmer put every use of Foo? in a dependently typed block is
> insane.

This is the eventual goal of Vala's support for non-nullable reference
types. However, this will not happen for Vala 1.x, at least not as
default. The reason is that if strict null checking is enabled without
good static analysis, it does more harm than it helps - compiler errors
in places where the expression can never be null.

Getting static analysis to a point where it's nice to work with strict
null checking is far from trivial. Just supporting `if (f != null)' is
not good enough in my experience. You'd end up with a lot of nullable =>
non-null casts, and this cannot be the goal.

I welcome experiments with the --enable-non-null-experimental mode, and
if and when we can get it to a usable state, we can consider enabling it
by default for the next major version.

Jürg