www.digitalmars.com         C & C++   DMDScript  

D - null casting (literal zero should be typeless)

reply "Luna Kid" <lunakid neuropolis.org> writes:
Of course, there should be no integer-pointer conversion.

But 0 is not an integer and not a pointer. It's typeless.

How about allowing to convert the literal 0 to any type
that is known to have a zero value? (That means at least
the built-in types.) I like this in C++.

Sz.
Aug 23 2003
next sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Luna Kid" <lunakid neuropolis.org> escreveu na mensagem
news:bi7ckk$19v6$1 digitaldaemon.com...
 Of course, there should be no integer-pointer conversion.

 But 0 is not an integer and not a pointer. It's typeless.

 How about allowing to convert the literal 0 to any type
 that is known to have a zero value? (That means at least
 the built-in types.) I like this in C++.

 Sz.

We could follow the Haskell way and make all literals convertible, provided a fromInt function and a fromDouble function. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.510 / Virus Database: 307 - Release Date: 14/8/2003
Aug 23 2003
prev sibling next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
"Luna Kid" <lunakid neuropolis.org> a écrit dans le message de
news:bi7ckk$19v6$1 digitaldaemon.com...
 Of course, there should be no integer-pointer conversion.

 But 0 is not an integer and not a pointer. It's typeless.

 How about allowing to convert the literal 0 to any type
 that is known to have a zero value? (That means at least
 the built-in types.) I like this in C++.

 Sz.

For overloadding purpose, I would prefer that 0 would prefer any conversion to integral type before conversion to pointer if we allows 0 for pointer. In fact, I think that it would be preferable to prohibit 0 for pointers and always uses a special nil keyword for that (does D have it ?). I have no problem if implicit conversions are allowed provided than for overload, 0 prefer integer types (and it would be an error if an ambiguities occurs)
Aug 23 2003
prev sibling next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Luna Kid" <lunakid neuropolis.org> wrote in message
news:bi7ckk$19v6$1 digitaldaemon.com...
 Of course, there should be no integer-pointer conversion.

 But 0 is not an integer and not a pointer. It's typeless.

 How about allowing to convert the literal 0 to any type
 that is known to have a zero value? (That means at least
 the built-in types.) I like this in C++.

D has 'null' for pointer and objects, which allows D to work on a system that had a none 0 null (some GC systems use several 'null' values non of which are 0 forcing null to 0 or assuming null is 0 (as C programmers tend to) may in the future cause problem on some systems ) 0 is an int value (undefined length or sign) , 0.0 is the '0' of floating type (again any length) and null is the "0" of all pointer and ref types. what benifit is gained by allowing '0' to mean all three, when convertions are requires to switch any other value between these types. you would not write int i = 0; Object foo = i; so why require int i = 0; Object foo = 0; especially when int i = 0; Object foo = null; is actually meaningfull.
Aug 23 2003
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 But 0 is not an integer and not a pointer. It's typeless.


I just thought math/physics... And sorry about any possible confusion: I didn't mean conversion or low-level issues like null-pointer bit-patterns etc. I really meant that "literal zero", as the *symbol*. The compiler (almost (*)) always knows the context to decide what a literal 0 should mean: for all the types that are known to have a ("dedicated") zero value (and all the built-ins do), "0" is the most natural and unambiguous name for those zero values (whatever their internal representation may be). (*) Note: when the compiler does not know the context, casting should be the way to help it out. For one, I always tried to avoid writing out 0.0 to indicate float, or at least looked around first hoping noone was watching... It's just so lame! In math and physics you can do it the clean way. Why not in CS? You cannot mix (convert) "types" like weight or speed or time, but in physics you are still free to use a plain "0" to mark them when zero, without "calling them names" in your equations, like "weightlessness" or "steadiness". ;) So, to reverse your question:
 what benifit is gained by allowing '0' to mean all three

What benefit is gained by inventing different kinds of 0s? At least I can't immediately see what's there beyond using "null" for documentation purposes. That's a valid reason, and I *do* like null or nil etc., but why are they not just plain alias names of 0? (BTW: 0 naturally and smoothly fits even the abstract function notation in C++ -- meaning perhaps nothing to our subject now, though...) It is not an important thing, though. I was just wondering. Sz.
Aug 23 2003
next sibling parent "Luna Kid" <lunakid neuropolis.org> writes:
 But 0 is not an integer and not a pointer. It's typeless.


I just thought math/physics...

...and forgot that math and physics are ALL ABOUT NUMERIC TYPES... :-) Matthew Wilson put it right (in news:bi8m7b$bij$1 digitaldaemon.com):
 I think 0 should be convertible only to numeric types, null only to
 reference (and pointer) types, and we should have separate symbol -
 "nothing" - that converts to anything.

Sz.
Aug 23 2003
prev sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 The compiler (almost (*)) always knows the context to decide
 what a literal 0 should mean: for all the types that are
 known to have a ("dedicated") zero value (and all the built-ins
 do), "0" is the most natural and unambiguous name for those
 zero values (whatever their internal representation may be).

     (*) Note: when the compiler does not know the
     context, casting should be the way to help it out.
     For one, I always tried to avoid writing out 0.0 to
     indicate float, or at least looked around first hoping
     noone was watching... It's just so lame! In math and
     physics you can do it the clean way. Why not in CS?

I don't like casting as overusing casting will make maintenance more difficult. Say for example, that something was an int but you notice by using the software that you need more precision or a bigger range and then decide to uses flotting points. If casting is almost not used, you can rely on the compiler to find most problems and the code will almost immediatly works as expected. OTOH, if casting is used a lot, then there might be some undesired conversion to the casted type that remain in the code. If I have a class with a constructor that accept an int, will 0 and null have a different meaning. If so, then it is definitevely prefereable that we cannot mix them... If reference can be initialised to a nil object, the null keyword should be used. For pointers, it is probably less a problem since 0 would always mean the pointer (as in C++). Finally, for overload, if I have the following overload: void f(bool); // 1 void f(int); // 2 void f(uint); // 3 void f(aclass &r); // 4 void f(apointer *p); // 5 void f(double d); // 6 void f(char c); // 7 void f(wchar w); // 8 Note: I'm not sure for the syntax for pointers and references in D so the declaration might be incorrect if not as in C++. Then: f(false); // calls 1 f(0); // calls 2 f(0u); // calls 3 f(null); // calls 5 (or ambiguous if reference are also initialised to null that way.) f(0.0); // calls 6 f('\0'); // calls 7 f(L'\0'); // calls 8 So we should uses the best match and have an ambiguities if there are 2 equivalent matches... And some conversions should never be allowed for initialisation: - null can only initialise pointers (or ref if supported) - false can only initialise pointers - 0.0 can only initialise flotting point - 0 can initialise any integer - ... If a suffix is used, it change the type of the expression and the preference for overload... We should not have the defect that C++ have where any 0 constant are considered equivalent. For exemple, in C++, if we have g(char); // a g(int); // b g('\0'); // calls b instead of expected We dont have to either declare a variable (a constant) or do an explicit cast to call a instead of b with a nul char constant... For assignment, conversions are allowed but some will cause a warning without any explicit cast... 0 can be used when there is no ambiguities for initialisation: double d = 0; // ok bool b = 0; // ok; and we could used zero or int_zero or something similar if we only wants an int: cont int zero = 0; zero will have type int... if used for initialisation: f(zero); // calls 2; This can be extended for any desired types --- I think that the rule should be that each form of 0 have their associated type (0 --> int, 0.0 --> double, ...) and we they do the same as if the call was made with that type... If no match are possible (or the match causes a warning), we the check if implicit conversion is allowed from a 0 of that form to the target type... and that no other euivalent conversion are possibles (and would be ambiguous). For ex.: h(bool); h(double); h(0); We don't have a best match...and we have 2 implicits possible conversion of the same level (we may choose different ordering), thus the call is ambiguous... So essentially for each form of the 0 constant, we have 1 best match, and then a few different level of conversion (for ex. we may want that 0 match better unsigned int than double). Note that some of those would apply to other constant as 1, 2,... The best match an int but there are allowed conversions and some are prefered over some others.
Aug 23 2003
prev sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
I think 0 should be convertible only to numeric types, null only to
reference (and pointer) types, and we should have separate symbol -
"nothing" - that converts to anything.

Alternatively we could have
  zero - numeric
  null - reference
  0 - anything

but I don't like that as much

The reason for such things is to

 (i) help avoid maintenance surprises when you may change the types of some
arguments from numeric to reference (or pointer)
 (ii) it is very useful for constraining generic (template) code to
only-numerics, or only-reference types, without having a gazillion traits
specialisations and all that heinous junk

"Luna Kid" <lunakid neuropolis.org> wrote in message
news:bi7ckk$19v6$1 digitaldaemon.com...
 Of course, there should be no integer-pointer conversion.

 But 0 is not an integer and not a pointer. It's typeless.

 How about allowing to convert the literal 0 to any type
 that is known to have a zero value? (That means at least
 the built-in types.) I like this in C++.

 Sz.

Aug 23 2003
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bi8m7b$bij$1 digitaldaemon.com...

 The reason for such things is to

  (i) help avoid maintenance surprises when you may change the types of some
 arguments from numeric to reference (or pointer)

Mmm, I'm still not comfortable about what those maintenance surprises could be. (Do they not originate in other problems actually?)
  (ii) it is very useful for constraining generic (template) code to
 only-numerics, or only-reference types, without having a gazillion traits
 specialisations and all that heinous junk

Good point, but even here, the 0/null thing looks to me like a random kludge, than a real solution (lacking explicit support for something like type categories?). I'm really just wondering. Thanks, Sz.
Aug 23 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
 Good point, but even here, the 0/null thing looks
 to me like a random kludge, than a real solution
 (lacking explicit support for something like type
 categories?).

 I'm really just wondering.

I dunno. I'm a pragmatist, not a theoretician.
Aug 23 2003