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

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

On 08/15/2009 02:59 AM, Sam Danielson wrote:
> 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.

I'm more talking about the fact that you can't technically get a null 
without assigning it yourself or via nullable return type (in which 
case, you need to check it as part of processing the result in any case).
Given that, strictly checking nulls on variables would do no difference 
IMO except requiring programmers type one character more. Most (if not 
all) potential null related programming errors are already eliminated 
via return value and argument checking.

>   What, specifically, is too complicated about
> the analysis? Perhaps I am being naive.
>
>    

Beats me, I'm just quoting Juerg from IRC. He said something about 
difficulty with getting it right in all cases. False positives 
complicating programmer's life and such stuff.

> -Sam Danielson
>