• Luna Kid (6/6) Aug 23 2003 Of course, there should be no integer-pointer conversion.
• Daniel Yokomiso (8/14) Aug 23 2003 We could follow the Haskell way and make all literals convertible, provi...
• Philippe Mori (10/16) Aug 23 2003 For overloadding purpose, I would prefer that 0 would prefer
• Mike Wynn (21/26) Aug 23 2003 why ?
• Luna Kid (30/33) Aug 23 2003 I just thought math/physics...
• Luna Kid (4/10) Aug 23 2003 ...and forgot that math and physics are ALL
• Philippe Mori (89/100) Aug 23 2003 I don't like casting as overusing casting will make maintenance
• Matthew Wilson (16/22) Aug 23 2003 I think 0 should be convertible only to numeric types, null only to
• Luna Kid (11/17) Aug 23 2003 Mmm, I'm still not comfortable about what those
• Matthew Wilson (1/6) Aug 23 2003 I dunno. I'm a pragmatist, not a theoretician.

"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.

"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

"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)

"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.

why ?

 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.

"Luna Kid" <lunakid neuropolis.org> writes:

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

 why ?

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.

"Luna Kid" <lunakid neuropolis.org> writes:

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

 why ?

 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.

"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.

"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.

"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.

"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.