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

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

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

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

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

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

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

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

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