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.so...@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
