<div dir="ltr">2008/7/24 Stephen Sinclair <<a href="mailto:radarsat1@gmail.com">radarsat1@gmail.com</a>>:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Agreed. The && operator does an implicit cast to boolean values, so<br>
it should work, since it shouldn't actually be comparing int and time,<br>
but comparing two booleans which have been derived from int and time.<br>
I'd say its a bug.<br>
<br>
</blockquote><div><br>Yes, that's how I look at it as well. <br><br>Behind the scenes, BTW, it turns out "true" is treated as a integer (we don't have booleans at all), at least according to the error messages but that doesn't matter much. Stefan is right that we can't go casting anything into anything, but we're not; we are evaluating the value for being non-zero, which is different and in fact has been shown to work already for single clauses.<br>
</div></div><br>I ran into it, BTW, stuffing a command (storing now, which itself returns "now" of type "time") into the condition of a "if" clause to make sure it only ran if the first check was valid yet regardless of the third and last condition. You can wonder whether that's good practice but I was four or five tabs deep already and this (would have) saved an extra one. With the improvement to if-clause parsing of two or so versions ago this has become more important since using multiple clauses is more powerful now.... but I can definitely see how this was previously overlooked.<br>
<br>I'll add it to the Wiki as a bug, if Ge disagrees we can remove it again but right now I say "bug".<br><br>Yours,<br>Kas.<br></div>