On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:

> So, let's ask the community: Would you like to see nullable types in D?
> 
> http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse
> by voting multiple time)
> 
> Explain your reasoning in newsgroups. Thank you.

i vote yes, i would absolutely love non-nullable types. in some cases i even use dummy objects to avoid null checks.

> On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:
>
>> So, let's ask the community: Would you like to see nullable types in D?
>>
>> http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse
>> by voting multiple time)
>>
>> Explain your reasoning in newsgroups. Thank you.

Yes: You don't always need an object to be nullable, and in those cases, having it nullable only serves to create a need for extra checking (Take a look at the ANTLR/StringBuilder Java source to see what happens when nullability goes too far. Disclaimer: I don't mean that as a jab at ANTLR/StringBuilder or the people behind it).

However, I could be swayed to change my mind against it if it were shown that nullable/nonnullable could not be done without ending up with a bunch of compatibility/conversion/API problems.

BTW, May I politely refer whoever used/made micropoll to the "OT: Scripting on websites [Was: Re: QtD 0.1 is out!]" sub-discussion over on digitalmars.D.announce? ;-)

Brian wrote:

> On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:
> 
>> So, let's ask the community: Would you like to see nullable types in D?
>> 
>> http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse
>> by voting multiple time)
>> 
>> Explain your reasoning in newsgroups. Thank you.
> 
> i vote yes, i would absolutely love non-nullable types. in some cases i even use dummy objects to avoid null checks.

Please, please give us non-nullable types!  Use of a non-nullable reference type before initialization could be an error just like it is in C#.  I hate segfaults and this would at least allow safer code to be written.  Non-nullable types should be implicitly castable to nullable types when making function calls that don't support them.

I vote yes.

I was pretty sure the topic was refering to the ability to specify a pointer that could not be set to 0.

I totally agree with this rule, and enforce it in all my C++ code with smart pointers.

class X
{

};

X x; //in D
or X * x; //in C++

Setting x to zero or any other value that is not the address of an instance of X is bad bad bad, and should be discouraged at all costs.

If I ask for a pointer to an instance of X and you give me a zero or 0x0123456 or anything else, it is like mixing in a bicycle when a recipe asked for a cup of olive oil.

This is a huge source of bugs where people best described as C programmers do C++.

In D the mistake can be made especially when a struct changes into a class, and allocations are not changed. Like X x has to change to X x = new X (which is a bit repetitive in D IMHO).
I think the default should be to have the native X x (D pointer to class) to be instantiating the class, and the X x = new Y should only be required when X and Y are different (inherited) types and
X x(32); when the class X has a ctor with arguments ( actually why don't I start a new thread about this)
There are many better ways to write code than using nullable pointers.

Jason House:
> Non-nullable types should be implicitly castable to nullable types when making function calls that don't support them.

An explicit cast may be better/safer.

Bye,
bearophile

Alex Burton:
> ( actually why don't I start a new thread about this)

I suggest you to start a new thread (and to try to explain yourself a bit better).

Bye,
bearophile

On 2009-02-08 23:19:55 -0500, Brian <digitalmars@brianguertin.com> said:

> On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:
> 
>> So, let's ask the community: Would you like to see nullable types in D?
>> 
>> http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse
>> by voting multiple time)
>> 
>> Explain your reasoning in newsgroups. Thank you.
> 
> i vote yes, i would absolutely love non-nullable types. in some cases i
> even use dummy objects to avoid null checks.

Same here.

A non-nullable pointer, when used as a function argument, is a contract the compiler can enforce at the call site. If 80% of your functions accept only non-nullable pointers, then it means you can remove about 80% of your checks for null without worries of seeing your program crash.

For global and member variables, non-nullable pointers means you can get an error exactly where the infringing code first put a null where there shouldn't be one; not later when someone tries to access it.

And I think non-nullable should be the default because it's safer and it'd force people to be explicit when they want to take the responsability to work with nullable ones.

So it's a yes.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Brian wrote:
> On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:
> 
>> So, let's ask the community: Would you like to see nullable types in D?
>>
>> http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse
>> by voting multiple time)
>>
>> Explain your reasoning in newsgroups. Thank you.
> 
> i vote yes, i would absolutely love non-nullable types. in some cases i even use dummy objects to avoid null checks. 

This is called the Null Object Pattern. Often, you need a special instance or subclass to satisfy the NOP. For instance, my company's staff scheduling program might get a null EmployeeGroup class that would need a reference to the Customer object, unlike other EmployeeGroups, in order to claim that it contains all employees.

Brian wrote:
> On Mon, 09 Feb 2009 04:25:55 +0300, Denis Koroskin wrote:
> 
>> So, let's ask the community: Would you like to see nullable types in D?
>>
>> http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse
>> by voting multiple time)
>>
>> Explain your reasoning in newsgroups. Thank you.
> 
> i vote yes, i would absolutely love non-nullable types. in some cases i even use dummy objects to avoid null checks. 

Oh, and I vote no. I think it's needless complexity. I code without any special care for null objects, and I get a segfault or NullReferenceException maybe once a week, probably less. I've always been able to track down the bug very quickly.

Having types be non-nullable by default would harm my productivity a fair bit. Having them be optionally non-nullable would be okay, as long as the libraries I use don't use non-nullable types.

bearophile wrote:
> Jason House:
>> Non-nullable types should be implicitly castable to nullable types when making function
>> calls that don't support them.
> 
> An explicit cast may be better/safer.

Non-nullable types are proper subtypes of nullable types. There is no added safety in requiring a cast.

Andrei