www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why is null lowercase?

reply Matthew Caron <matt.caron redlion.net> writes:
This is probably a question for Walter, but maybe others know.

Of all of the differences between C and D, the one which I have the most 
difficulty adapting to is null being lowercase. Does anyone know why 
this decision was made?
-- 
Matthew Caron, Software Build Engineer
Sixnet, a Red Lion business | www.sixnet.com
+1 (518) 877-5173 x138 office
Jan 24 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Matthew Caron:

 Of all of the differences between C and D, the one which I have 
 the most difficulty adapting to is null being lowercase. Does 
 anyone know why this decision was made?
Probably because writing all in uppercase ugly. null is a keyword like the others, and they are in lowercase. DO YOU PREFER A LANGUAGE ALL IN UPPERCASE? Bye, bearophile
Jan 24 2013
parent "Phil Lavoie" <maidenphil hotmail.com> writes:
 DO YOU PREFER A LANGUAGE ALL IN UPPERCASE?
Hahahaha! I find it ugly too. I prefer lowercaps null, as in Java.
Jan 27 2013
prev sibling next sibling parent "Mike Parker" <aldacron gmail.com> writes:
On Thursday, 24 January 2013 at 12:56:03 UTC, Matthew Caron wrote:
 This is probably a question for Walter, but maybe others know.

 Of all of the differences between C and D, the one which I have 
 the most difficulty adapting to is null being lowercase. Does 
 anyone know why this decision was made?
In the world of C and C++, 'NULL' is a macro. Macros, by convention, are all uppercase. Contrast that with C++11 which provides for 'nullptr', a type rather than a macro. Consider Java, which also has a lowercase null. In D, null follows the same convention as other built-ins, so it is lowercase. To me, it makes perfect sense. There are no macros in D, so I wouldn't have expected to see NULL to begin with. *That* would have been highly inconsistent.
Jan 24 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 24 January 2013 at 12:56:03 UTC, Matthew Caron wrote:
 This is probably a question for Walter, but maybe others know.

 Of all of the differences between C and D, the one which I have 
 the most difficulty adapting to is null being lowercase. Does 
 anyone know why this decision was made?
Keep in mind that strictly speeking, "NULL" != "null": NULL is a C macro that expands to 0. null is a D keyword that cannot be implicitly cast to an integer. This is a source of bugs: //---- void foo(int); void foo(int*); //---- in C++: foo(NULL); //Calls "void foo(int)" in D: foo(null); //Calls "void foo(int*)" Having code that is valid in both C++ and D, but having a different behavior would be VERY bad. -------- BTW, you can be thankful that it is *just* "null", because what it really is C++11's "null_ptr". Which is worst.
Jan 24 2013
prev sibling next sibling parent Leandro Motta Barros <lmb stackedboxes.org> writes:
Hi,

In C, NULL is a #define, and #defines are typically all-caps. In D,
null is real keyword recognized by the compiler, and those are
typically lowercase. I am just guessing here, but I'd say the choice
for 'null' instead of 'NULL' is just to be coherent with this.

Personally, I kinda like 'null'. :-)

LMB




On Thu, Jan 24, 2013 at 10:56 AM, Matthew Caron <matt.caron redlion.net> wrote:
 This is probably a question for Walter, but maybe others know.

 Of all of the differences between C and D, the one which I have the most
 difficulty adapting to is null being lowercase. Does anyone know why this
 decision was made?
 --
 Matthew Caron, Software Build Engineer
 Sixnet, a Red Lion business | www.sixnet.com
 +1 (518) 877-5173 x138 office
Jan 24 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Thursday, 24 January 2013 at 12:56:03 UTC, Matthew Caron wrote:
 This is probably a question for Walter, but maybe others know.

 Of all of the differences between C and D, the one which I have 
 the most difficulty adapting to is null being lowercase. Does 
 anyone know why this decision was made?
You'll get used to it, it's actually much better than typing in NULL, and it's a real type instead on an int, which never worked well in C. Just be warned that when checking for null *do not* use equality operator if ( ptr == null) ... instead use the identity operator "is" if ( ptr is null) ... for not null checks if ( ptr !is null) ... BTW, half of what you thought worked well in C/C++ will get turned upside down if you stick with D, and once you get it, moving back to C/C++ becomes unbearable. --rt
Jan 24 2013
parent reply Matthew Caron <matt.caron redlion.net> writes:
On 01/24/2013 12:04 PM, Rob T wrote:
 You'll get used to it, it's actually much better than typing in NULL,
 and it's a real type instead on an int, which never worked well in C.

 Just be warned that when checking for null *do not* use equality operator
Yeah, the compiler helped me find that one out. That takes a little getting used to as well. Old habits and such.
 for not null checks

 if ( ptr !is null) ...
And too much perl has me wanting to write: if (ptr is not null)
 BTW, half of what you thought worked well in C/C++ will get turned
 upside down if you stick with D, and once you get it, moving back to
 C/C++ becomes unbearable.
It already is. I have very little desire to do anything in any other with native libraries as I'd like and require a whole VM which consumes gobs of memory and takes forever to start. D gives me the features I terms of speed. I can get more done, faster, in D. Meanwhile, it seems like the rest of the world is moving towards writing everything in JavaScript, and that's just leaving me scratching my head in amazement. -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Jan 24 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/24/2013 12:42 PM, Matthew Caron wrote:

 for not null checks

 if ( ptr !is null) ...
And too much perl has me wanting to write: if (ptr is not null)
IIRC, the !is operator is thanks to bearophile. We would have to reverse the logic before he insisted on !is: :) if (!(ptr is null)) Ali
Jan 24 2013
parent reply "Don" <don nospam.com> writes:
On Friday, 25 January 2013 at 01:17:44 UTC, Ali Çehreli wrote:
 On 01/24/2013 12:42 PM, Matthew Caron wrote:

 for not null checks

 if ( ptr !is null) ...
And too much perl has me wanting to write: if (ptr is not null)
IIRC, the !is operator is thanks to bearophile.
No, it's from 2002 (well, it was !==, renamed to !is in 2005). Bearophile only joined us about the time D2 began, in late 2007.
Jan 25 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/25/2013 06:22 AM, Don wrote:

 IIRC, the !is operator is thanks to bearophile.
No, it's from 2002 (well, it was !==, renamed to !is in 2005). Bearophile only joined us about the time D2 began, in late 2007.
Ok. How about !in then? Did he lobby for that one? :) Ali
Jan 25 2013
parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 25 January 2013 at 14:43:01 UTC, Ali Çehreli wrote:
 On 01/25/2013 06:22 AM, Don wrote:
 No, it's from 2002 (well, it was !==, renamed to !is in 2005). 
 Bearophile only joined us about the time D2 began, in late 
 2007.
Ok. How about !in then? Did he lobby for that one? :)
//hmmm doesn't read right if (ptr in not null) //huh? is it an array or an AA now? if (ptr not in null) //ummm feels like an AA. I'm sure if we used //it it would become second nature. if (ptr !in null) //silently converts to...? if (!(ptr in null)) //make sense to me. Course in java === was //used for ptr checking rather than contents. if (ptr === null) //is null if (ptr !== null) //not null, both stand out //mentally I reverse !is to equal 'is not'. //I know I'm comparing pointers. if (ptr !is null) Code example: string[string] aa; string* ptr; if ("dog" in aa) //returns ptr if ("dog" !in aa) //i think it's bool of 'found' ptr = "dog" in aa; if (ptr in null) //errors, not an aa, searching null? if (ptr !in null) //not searching null? change to... string[string[string]] aa; string[string]* ptr; //(string[string])* ptr; ?? if ("dog" in aa) //returns ptr (of an aa), search if ("dog" !in aa) //still makes sense... a search. ptr = "dog" in aa; if (ptr in null) //becomes ((*ptr) in aa), search? //(!((*ptr) in null))//AA search or pointer compare? if (ptr !in null) null can still be replaced by any variable/pointer, if that pointer is an aa as well... Ugg I don't wanna find out all the combinations to figure it out... After looking at all these 'in' should be reserved for array searching, not pointer checking. It makes more sense to me that way.
Jan 25 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/25/2013 10:31 AM, Era Scarecrow wrote:
 On Friday, 25 January 2013 at 14:43:01 UTC, Ali Çehreli wrote:
 On 01/25/2013 06:22 AM, Don wrote:
 No, it's from 2002 (well, it was !==, renamed to !is in 2005).
 Bearophile only joined us about the time D2 began, in late 2007.
Ok. How about !in then? Did he lobby for that one? :)
 //ummm feels like an AA. I'm sure if we used
 //it it would become second nature.
 if (ptr !in null)
Isn't that an error to apply the in operator to null? The expression above is syntactic sugar for the following one: !null.opBinaryRight!"in"(ptr)) Yes, there is also opBinary!"in" but it doesn't make sense to me to put the container on the left-hand side ever: if (myContainer in myElement) Doesn't make sense.
 After looking at all these 'in' should be reserved for array searching,
 not pointer checking. It makes more sense to me that way.
Sorry if I implied otherwise. Yes, 'in' should be for that purpose. I merely tried to remember what syntax has been bearophile's strong suggestion. ;) Ali
Jan 25 2013
parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Friday, 25 January 2013 at 18:57:06 UTC, Ali Çehreli wrote:
 On 01/25/2013 10:31 AM, Era Scarecrow wrote:
 After looking at all these 'in' should be reserved for array 
 searching, not pointer checking. It makes more sense to me 
 that way.
Sorry if I implied otherwise. Yes, 'in' should be for that purpose. I merely tried to remember what syntax has been bearophile's strong suggestion. ;)
Not so much implied as considered. Had it been used, it would be obvious there was problems with it, both with meanings and added ambiguities. Oh well. One thing at a time..
Jan 25 2013
prev sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Friday, 25 January 2013 at 14:22:20 UTC, Don wrote:
 On Friday, 25 January 2013 at 01:17:44 UTC, Ali Çehreli wrote:
 On 01/24/2013 12:42 PM, Matthew Caron wrote:

 for not null checks

 if ( ptr !is null) ...
And too much perl has me wanting to write: if (ptr is not null)
IIRC, the !is operator is thanks to bearophile.
No, it's from 2002 (well, it was !==, renamed to !is in 2005). Bearophile only joined us about the time D2 began, in late 2007.
It would be nice a to have a wiki page about D history written by old-timers.
Jan 25 2013
parent "Phil Lavoie" <maidenphil hotmail.com> writes:
On Friday, 25 January 2013 at 16:11:57 UTC, Maxim Fomin wrote:
 On Friday, 25 January 2013 at 14:22:20 UTC, Don wrote:
 On Friday, 25 January 2013 at 01:17:44 UTC, Ali Çehreli wrote:
 On 01/24/2013 12:42 PM, Matthew Caron wrote:

 for not null checks

 if ( ptr !is null) ...
And too much perl has me wanting to write: if (ptr is not null)
IIRC, the !is operator is thanks to bearophile.
No, it's from 2002 (well, it was !==, renamed to !is in 2005). Bearophile only joined us about the time D2 began, in late 2007.
It would be nice a to have a wiki page about D history written by old-timers.
I vote for that too!
Jan 27 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/24/2013 04:56 AM, Matthew Caron wrote:
 This is probably a question for Walter, but maybe others know.

 Of all of the differences between C and D, the one which I have the most
 difficulty adapting to is null being lowercase. Does anyone know why
 this decision was made?
Similarly, the common macros TRUE and FALSE are replaced by the 'true' and 'false' keywords. Ali
Jan 24 2013
parent Matthew Caron <matt.caron redlion.net> writes:
On 01/24/2013 12:50 PM, Ali Çehreli wrote:
 Similarly, the common macros TRUE and FALSE are replaced by the 'true'
 and 'false' keywords.
Ironically, those don't bother me because I never used them. -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Jan 24 2013