Much of this is due to that the type system doesn't completely correspond to the actual value sets. E.g. the string type includes zero and all "real" strings, but the value zero has almost completely different properties than the other string values. It's very common with functions that take string arguments and still don't accept zero, and then they complain that zero isn't a string.
I'd like this to be fixed in the long run, perhaps for Pike 8, so that the reference types don't include zero in their value sets. If you want to allow zero then be explicit about it and use string|zero.
The initial value problem could be fixed by
1. defaulting to "", ({}) etc as appropriate (but that gives an ambiguity problem for variables of type string|array etc),
2. always requiring an initialization, or
3. add rules to make it possible to check at compile time that a variable always is initialized before its first use. That could be tricky due to the dynamic nature of Pike, though.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-23 10:49: Subject: Re: zero_type() & UNDEFINED and _typeof()
On Thu, Jan 23, 2003 at 10:05:02AM +0100, Niels Möller () @ Pike (-) developers forum wrote:
What's the problem with variables being automatically initialized to zero?
that it's only ints that are actually initialized to value of their own type, while everything else is clearly distinguishable from a real value. (if that is a problem :-)
To me, having more than one "null value" for strings seems utterly useless.
i agree with that, if 0 looses its special meaning, then a string (or any non int variable) should never get the value 0.
things that irritate are:
string foo; sprintf("%s", foo);
Sprintf: Wrong type for argument 2: expected string, got int.
where i'd rather read:
Sprintf: Wrong type for argument 2: string is UNDEFINED.
which more clearly indicates that foo has an unacceptable value, but not an unacceptable type.
or:
foo+="bar";
(1) Result: "0bar"
the automatic cast of strings with value 0 to "0" in many string operations is an equal irritation where i'd rather get an exception.
compare this to:
array bar; bar+=({ "baz" });
Bad argument 2 to `+(). Expected int
which does raise an exception. although the errormessage seems rather odd too:
Bad argument 1 to `+(). array is undefined.
is, what one would like to read here.
however all things said, the compatibility issues involved may make the whole discussion moot...
greetings, martin.
/ Brevbäraren