I think of zero as a real and valid value for a string variable. Perhaps I've gotten too used to C's NULL value.
For your other comments, I agree that printf could display a better error message, and I really hate the automatic int->string conversion. But that doesn't mean that I don't think initialization to zero is ok.
As for arrays, automatic initialization to an empty array would be useful, but it's no big deal to have to write array bar = ({}); when that's what you want.
/ Niels Möller ()
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