Lints, Condate and bugs

[dennis luehring]

Am 29.10.2010 13:41, schrieb tls:
> dennis luehring Wrote:
>
>>  Am 29.10.2010 11:07, schrieb Denis Koroskin:
>>  >  On Fri, 29 Oct 2010 11:58:56 +0400, dennis luehring<dl.soluz at gmx.net>
>>  >  wrote:
>>  >
>>  >>   Am 29.10.2010 09:26, schrieb Roman Ivanov:
>>  >>>   They would be a great help in debugging programs, for example.
>>  >>>   NullPointerException is probably the most common error I see in Java.
>>  >>>   95% of all times it gets thrown in some weird context, which gives you
>>  >>>   no idea about what happened. The result is a long and tedious debugging
>>  >>>   session.
>>  >>
>>  >>   100% correct - but to have null-able types help to writer code faster in
>>  >>   the prototype phase, and not having them will also change the way
>>  >>   developers are "forced" to write code
>>  >>
>>  >>   and there are million developers out there who likes/and use null-able
>>  >>   values for flow-control - if the null-able "feature" is removed without
>>  >>   something that keeps the style working, you will loose them, or much
>>  >>   more evil, they will try to code around the non-null-able-style getting
>>  >>   back to there well known null-able behavior, by using bools, ints,
>>  >>   strings whatever ->   that will not help in library growth around D
>>  >>
>>  >>   try comming up with an pattern that keeps both pro/cons...
>>  >
>>  >  No one is talking about removing nullable references but rather adding
>>  >  non-nullable types and making them default. You could still achieve old
>>  >  behavior if it is needed (most proposed proposed syntax):
>>  >
>>  >  Foo? foo = stuff.find(predicate);
>>  >  if (foo is null) {
>>  >        // not found
>>  >  }
>>
>>   >  No one is talking about removing nullable references
>>  sorry
>>
>>   >  most proposed proposed syntax
>>  like it works in C# - but better because of "...and making them default." :)
>>
>>  sound very similar to the long talked about "make parameters const per
>>  default" proposal - which is also still not there :(
>
> const parameters no good per default. I reuse parameters whole time to space conservations. Imagine if browser need twice space for all functions, make them too big. Already needs 2 GigaB of my 4 GigaB system. We need fight bloat with every weapons. They fix this bug:
>
> this(int x, int y) {
>    x = x;
>    this.y = y;
> }
>
> but only bad coder make mistakes. D programmers old C++ veterans so make no mistakes ever.

in a library that is not written by you

should be:

void functionX( int& refered )
{
   refered = 10;
}

was mistakenly types as

void functionX( int refered )
{
   refered = 10;
}

now start to find the error in your million lines of code

i've usualy find errors like these in projects im involed in