[2.0.2] !!"0" == false

[CoolCmd]

According to the documentation, in places where boolean value is expected, string "0" is treated as true.
But the result of this script

Code: Select all

#Requires AutoHotkey v2
MsgBox !!"0"
MsgBox "0" ? true : false

is 0 and 0.

[boiler]

According to the documentation, in places where boolean value is expected, string "0" is treated as true.

Can you provide a link?

[CoolCmd]

https://www.autohotkey.com/docs/v2/Variables.htm#Boolean

When an expression is required to evaluate to true or false (such as an IF-statement), a blank or zero result is considered false and all other results are considered true.

https://www.autohotkey.com/docs/v2/Concepts.htm#boolean

When a value is required to be either true or false, a blank or zero value is considered false and all other values are considered true.

https://www.autohotkey.com/docs/v2/lib/If.htm#Remarks

If the If statement's expression evaluates to true (which is any result other than an empty string or the number 0)

etc.....

[boiler]

None of those links/quotes support what you said the documentation says. Each of them says that if the result is 0, it is considered false. None of them said what you said the documentation indicates, which is that the string "0" is treated as true.

In case you were to say that the string "0" is otherwise different than the numeric value 0 in AHK, run the following script (in either AHK version):

Code: Select all

if (0 = "0")
	MsgBox 1

[swagfag]

this is actually a semi-documented special case

Quoted literal strings and strings produced by concatenating with quoted literal strings are no longer unconditionally considered non-numeric. Instead, they are treated the same as strings stored in variables or returned from functions. This has the following implications:
•Quoted literal "0" is considered false.

but reading the if-statement documentation, it doesnt make any sense to me why that should be the case

If the If statement's expression evaluates to true (which is any result other than an empty string or the number 0)

• is '0' "an empty string"? no, its a non-empty string of length 1.
• is '0' "the number 0"? no, its the String(class) '0'.
• therefore, '0' is "any other result". therefore, "the expression [should] evaluate to true"

[joefiesta]

Boy, I totally agree with Swagfag. I can not imagine why anyone in the world would want the string "0" to be IN ANY WAY similar to the number 0. For one, they are stored differently (I assume... Ionly know about mainframe inner workings).

Further, and just as ridiculous, is this example, expanding to test "00".
(yes, rather primitive coding.... )

Code: Select all

if (0 = "0")
   msg1 := " true   : 0 = ""0"""
else
   msg1 := " false  : 0 does not = ""0"""
if (0 = "1")
   msg2 := " true   : 0 = ""1"""
else
   msg2 := " false  : 0 does not = ""1"""
if (0 = "00")
   msg3 := " true   : 0 = ""00"""
else
   msg3 := " false  : 0 does not = ""00"""
msgbox %  msg1 "`n" msg2 "`n" msg3
return

running in v1, case 3 shows just how horribly this is implemented currently.
0 ="0" is true, but 0 = "00" is false. what the heck? no wonder I still, after 15 years, find ahk confusing sometimes.

[TheArkive]

Call me crazy, but I actually find AHK to be consistent with itself on this point in my experience.

If a string can be interpreted as a number, then it is often treated as such, and has been that way as long as I can remember.

Some functions in AHK v2 have been changed to no longer accept a string or a number, but rather one or the other.

This "type friendliness" is helpful for new coders. It certainly helped me, even though I actually sometimes currently wish for stricter type checking with some of my projects.

I can understand more experienced coders being thrown for a loop though.

[lmstearn]

Does == make any difference here? From the Variables section"

The == and !== operators can be used to compare strings which contain binary zero. All other comparison operators except ~= compare only up to the first binary zero.

Up to and not including?

[TheArkive]

No, because both sides of the comparison need to be a string in order for there to be a difference.

[lexikos]

this is actually a semi-documented special case

No, it is generally the case that numeric strings can be evaluated numerically. In v1, there is the special case that quoted strings used immediately in an expression are treated as non-numeric, inconsistent with strings contained by variables. The documentation you quoted explains that this special case has been removed. Thus, there is no special case in v2, and the general case now applies to !!"0" just the same as it always applied to !!(x:="0").

For one, they are stored differently (I assume... Ionly know about mainframe inner workings).

0 and 0.0 are stored differently. They are not the same type, and yet they are of equal value.

In "mainframe inner workings", there are several more numeric types, so 0 may have several different representations (if only varying by number of bytes). Even within one floating-point format, there can be multiple combinations of bits which equate to zero. Likewise, numeric data can be encoded using ASCII or Unicode.

If you write a number on paper, it will likely not be represented by a sequence of bits, as in nearly all programs. Yet it's still a number.

[CoolCmd]

lexikos, can you update documentation so that it represent the actual behavior of interpreter? When are strings converted to number for boolean result?

[CoolCmd]

another one
https://www.autohotkey.com/docs/v2/lib/Until.htm

If the expression evaluates to false (which is an empty string or the number 0)