[v2] Numeric Strings Can Be Falsey

Report problems with documented functionality
User avatar
SALZKARTOFFEEEL
Posts: 89
Joined: 10 May 2017, 11:14
GitHub: SALZKARTOFFEEEL
Location: Germany
Contact:

[v2] Numeric Strings Can Be Falsey

21 Dec 2019, 11:52

https://lexikos.github.io/v2/docs/Concepts.htm#boolean wrote: 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
Posts: 3250
Joined: 11 Jan 2017, 17:59

Re: [v2] Numeric Strings Can Be Falsey

21 Dec 2019, 16:51

i think this was specifically changed in v2 to behave that way
v2 changes wrote: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
User avatar
SALZKARTOFFEEEL
Posts: 89
Joined: 10 May 2017, 11:14
GitHub: SALZKARTOFFEEEL
Location: Germany
Contact:

Re: [v2] Numeric Strings Can Be Falsey

21 Dec 2019, 17:05

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
Posts: 334
Joined: 24 Jan 2016, 13:54
Location: Pa., USA

Re: [v2] Numeric Strings Can Be Falsey

23 Dec 2019, 09:25

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
Posts: 2927
Joined: 09 Oct 2013, 10:31

Re: [v2] Numeric Strings Can Be Falsey

23 Dec 2019, 09:47

joefiesta wrote:
23 Dec 2019, 09:25
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?

User avatar
kczx3
Posts: 959
Joined: 06 Oct 2015, 21:39

Re: [v2] Numeric Strings Can Be Falsey

23 Dec 2019, 14:23

guest3456 wrote:
23 Dec 2019, 09:47
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
Posts: 3250
Joined: 11 Jan 2017, 17:59

Re: [v2] Numeric Strings Can Be Falsey

23 Dec 2019, 14:34

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
Posts: 4072
Joined: 17 Jul 2016, 01:02
Contact:

Re: [v2] Numeric Strings Can Be Falsey

11 Jan 2020, 07:09

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,
pure numbers wrote: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 :beer:
Last edited by Helgef on 11 Jan 2020, 07:31, edited 1 time in total.
swagfag
Posts: 3250
Joined: 11 Jan 2017, 17:59

Re: [v2] Numeric Strings Can Be Falsey

11 Jan 2020, 07:30

eyyyyyy helgef is back

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 14 guests