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

[Jiří Zárevúcky <zarevucky jiri gmail com>]

On 08/14/2009 02:48 AM, Sam Danielson wrote:
> The following code compiles with no warnings with the 0.7.3 compiler
> and segfaults at runtime. I understand that nullable types can be null
> but why are regular reference types allowed to be null? I noticed that
> if the return type of make_foo is changed from Foo? to Foo I at least
> get a warning. But both assignments in main() go unnoticed.
>    

Why shouldn't they be null? IMO, it would just add much more trouble.
Checking nulls is responsibility of the programmer. That is consistent 
with every other language I know, including dynamic ones, C#, Java, etc.

> class Foo { public int i; }
> Foo? make_foo () { return null; }
> void main ()
> {
>         Foo f1 = make_foo ();
>         Foo f2 = null;
>         message (f1.i.to_string () + f2.i.to_string ());
> }
>
> I'm also curious how vala will handle a Foo? ->  Foo cast.
>    

I don't think I understand what you mean. For reference types, there is 
no technical difference between Foo and Foo?, except as the marking of 
arguments and return values that must not be null (that's checked in the 
method by simple assertions). You can't do any "cast" there.

You can use '?' to box simple types, though. There is a bug when casting 
them. For example, when casting int? to int, you get a pointer, not the 
value, so be careful with that. Simple assignment from nullable to 
normal int works fine.

> Will the
> type system be statically null-check aware, silently changing Foo? to
> Foo inside 'if (foo != null) {...}'?
>    
> -Sam Danielson
>
>