[v2] Numeric Strings Can Be Falsey

[SALZKARTOFFEEEL]

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.

This same sentence is present in the v1 docs, however, the behavior between the two versions differs.

In v2, a numeric string is, seemingly, evaluated numerically before its boolean truthfulness is tested. This has some unintuitive side-effects:

• "0" is false
• "0.0" is false
• "-0x00000000" is false
• etc.

I think this is a bug. A non-empty string should be considered truthy, no matter how it could be interpreted. There is nothing numeric about booleans (except their underlying type), so a string should not be evaluated as a number before a boolean check, in my opinion.
This behavior breaks parsers that use something like While SubStr(Str, Pos, 1) to traverse. The rather clumsy workaround is While (SubStr(Str, Pos, 1) !== "").

I have tested this on a107 and a108 (latest as of today).

[swagfag]

i think this was specifically changed in v2 to behave that way

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

personally id rather see this whole "numeric string" concept go and have string be strings and numbers be numbers and explicit cast from one another, otherwise ure faced with piling incoherent one-off corner case hotfixes until theres no tomorrow

[SALZKARTOFFEEEL]

I see.
While I personally don't think this is a good idea, I can see how this tradeoff was made.
In my opinion, the best thing would be to have a dedicated Boolean type so that a cast (be it automatic or not) from a string to a bool could be handled differently than a cast from a number to a bool. This would make "0" being truthy possible while keeping the feature you showed.

Anyways, those are just my two cents.
Thank you for pointing me to this and clearing it up!

[joefiesta]

my 2 cents worth: This treating of literals as numerics is ridiculous. Just another example of why AHK is the most convoluted and difficult programming language to learn that I have ever used in my 40 years of programming. Nothing but exceptions to so many rules.

[guest3456]

Just another example of why AHK is the most convoluted and difficult programming language to learn that I have ever used in my 40 years of programming

is AHK a programming language, or a scripting language geared toward non-programmers for simple automation tasks?

[kczx3]

is AHK a programming language, or a scripting language geared toward non-programmers for simple automation tasks?

Maybe it started that way but it has definitely become a programming language in my opinion.

[swagfag]

a scripting language is by definition a programming language, why even ponder that?
was ahk ever a language targeted at non-programmers? something GUI-like like PMC might fit the bill, ahk though - im not so sure.
id prefer the language to have sane definitions instead of relying on "X works as u, non-programmers, would expect, except for these 10% worth of edge cases, have fun tracking the bug, teehee"

[Helgef]

This is the intended behaviour, and it is the same in v1 except for when a quoted string is used directly in an expression, like,

Code: Select all

If "0"
    ;...

Which executes the if branch in v1 but not in v2. It's an inconsistency of v1 which has been fixed as quoted by swagfag above.
See,

In most cases, AutoHotkey automatically converts between numeric strings and pure numbers as needed, and rarely differentiates between the two types.

Cheers.

Edit, hi @swagfag

[swagfag]

eyyyyyy helgef is back