Why does a string used in an expression return 0?

[InunoTaishou]

I know on other languages when you try to use a string like this

Global $sString = "Some String"

If ($sString) Then
    ; ...
EndIf

The compiler will fail because string cannot be used in an expression where it needs a bool (something along those lines). But I see instances in other languages where using $sString in an expression will work and implicitly use the length of the string (or because there is some value in that variable).

I'm wondering why AutoIt doesn't do the same. If the $sString is used like in my example (or some other expression where it wants a bool type) implicitly use the length of the string instead of the converting to 0?

[Subz]

Isn't that what the _IsString(), _IsDeclared(), StringLen() functions are for?  From my logic:

If "Some String" Then ... doesn't really mean anything or maybe my logic is just screwed up  

[InunoTaishou]

But AutoIt implicitly converts any string used in an expression where it wants a true/false to 0 if that string is not a string representation of a number or true/false ("True" or "False"). If it's going to do that why not implicitly convert it to 1 if the string is not "" (empty/null string)?

IsString just checks if the variable is a string (I.e., 32 is not a string but "32" is)

_IsDeclared just checks if the string representation of the variable is declared in the script

and StringLen is what would be used currently

This is how we currently do it

Global $sString = "Some String"

While (StringLen($sString))
    ConsoleWrite($sString & @LF)
    $sString = StringTrimLeft($sString, 1)
WEnd

And this is how we could be doing it

Global $sString = "Some String"

While ($sString)
    ConsoleWrite($sString & @LF)
    $sString = StringTrimLeft($sString, 1)
WEnd

Seems like such an insignificant thing but it's surprisingly useful. I went from C++, VB, AutoIt to Python (where the latter does work) and it's so freaking nice being able to use the string as a boolean in an if statement

Edited April 22, 2017 by InunoTaishou

[Guy_]

I used to do that all over the place and am still correcting it when I see it

It seems a bit silly to have to write ...

If $sTring <> "" Then

If isEmpty($sTring) Then ... (in some languages)

But I guess there may be good reasons for it...
It's why it's good to first start studying the basics before you start tinkering. I'm still telling myself that every day...

[czardas]

It was an illogical decision IMO. I believe you should be able to use strings in boolean expressions. Actually it seems to be working. Which version of AutoIt are you using?

Edited April 22, 2017 by czardas

[InunoTaishou]

I just ran

Global $sString = "Some String"

While ($sString)
    ConsoleWrite($sString & @LF)
    $sString = StringTrimLeft($sString, 1)
WEnd

And it actually worked.... I don't know who did it, I don't know when it happened, but I swear this used to not work.... Strings used to always evaluate to 0 when used in a boolean expression.

Does this work for anyone else?

[czardas]

We are mistaking it for something else. This works for me.

If 'some string' Then MsgBox(0, '', 'hey')

Conversion of string to number is the oddball.

MsgBox(0, '', Number('3v')) ; converts to 3

I find that so illogical.

Edited April 22, 2017 by czardas

[InunoTaishou]

I remember very specifically that it didn't used to work, and was very frustrated by this. Looking back at a few old scripts I had to use things like Stringlen and Not $sString == ""

[czardas]

Maybe it was like that previously. I don't remember.

Edited April 22, 2017 by czardas

[iamtheky]

strings still evaluate to 0 in some cases, no?

msgbox("some string" , "some string" , "some string")

 

[czardas]

3 hours ago, iamtheky said:

strings still evaluate to 0 in some cases, no?

Could be two different things. A boolean comparison verses a default error override. I don't know.

Edited April 22, 2017 by czardas

[iamtheky]

maybe?

#include<array.au3>

local $aArray["zero elements please"]
_ArrayDisplay($aArray , ubound($aArray))

 

[czardas]

Of course you should never rely on undocumented behaviour.

#include<array.au3>

local $aArray["3 elements please"]
_ArrayDisplay($aArray , ubound($aArray))

In this case it certainly appears to be a conversion.

In addition: boolean comparisons between different data types may sometimes lead to (apparently) contradictory results.

Edit: This is also a conversion, and not the result of some default override value.

MsgBox('1 or 2', '', 'meh')

 

Edited April 22, 2017 by czardas

[jchd]

There is no more "contradictory results" than "some cases" or "random conversion behavior".

Well written computer programs are pretty bad at creating non-repeatable surprising behavior, contrary to humans. Instead, they hopefully exhibit very deterministic behavior which we all rely upon, else our lives would turn turmoil.

A string evaluates to its content when used in a string expression (or parameter of a function expecting a string). No surprise here.

It evaluates to a boolean in a boolean context: Flase if the string is empty, True if non-empty.

It evaluates to its numeric conversion (using Number()) when in a numeric context. Here an empty string evaluates to 0.

All of this always behaved the same for decade(s) AFAICT.

[iamtheky]

I have shown two cases where a non-empty (or empty) string evaluates to 0, I could understand that being a product of the msgbox function, but the behavior exists with declaring arrays as well.  And that behavior has existed as long as I have been trolling threads regarding magic numbers.

Edited April 22, 2017 by iamtheky

[jchd]

An dimension index is expected to be numeric, so Number is applied to the string, yielding zero. No surprise here either.

[iamtheky]

so this would be an expected solution if I needed arrays from a list?  because formatting seems like an extra rather than necessary step if the behavior is expected, but I never see it in action.

#include<array.au3>

$sList1 = "20 bottles"
$sList2 = "45 plates"
$sList3 = "200 cups"

local $aArray1[$sList1]
local $aArray2[$sList2]
local $aArray3[$sList3]

_ArrayDisplay($aArray1)
_ArrayDisplay($aArray2)
_ArrayDisplay($aArray3)

 

Edited April 22, 2017 by iamtheky

[jchd]

I don't believe the interpretor would get mad at you if you use that, albeit that useage might surprise future maintainers.

[InunoTaishou]

It's like we've had a breakthrough! Lol (Sorry I'm late, was busy yesterday)

I quite like the

#include<array.au3>

$sList1 = "20 bottles"
$sList2 = "45 plates"
$sList3 = "200 cups"

local $aArray1[$sList1]
local $aArray2[$sList2]
local $aArray3[$sList3]

_ArrayDisplay($aArray1)
_ArrayDisplay($aArray2)
_ArrayDisplay($aArray3)

Then you could give self documenting arrays self documenting values

#include<array.au3>

Global $aBeers["10 draught beers"]
$aBeers["0 Coors"] = "Coors"
$aBeers["1 Fosters"] = "Fosters"
$aBeers["2 Staropramen"] = "Staropramen"
$aBeers["3 Personi"] = "Personi"
$aBeers["4 Fuller’s London Pride"] = "Fuller’s London Pride"
$aBeers["5 Cruzcampo"] = "Cruzcampo"
$aBeers["6 Heineken"] = "Heineken"
$aBeers["7 San Miguel"] = "San Miguel"
$aBeers["8 Stella Artois"] = "Stella Artois"
$aBeers["9 Mockingfish"] = "Mockingfish"

_ArrayDisplay($aBeers)

(I don't drink, beer was just something that came to mind)

[czardas]

I said '(apparently) contradictory' results. Anyway, I don't like the numeric conversion of strings (current implementation) because it doesn't differentiate between valid and invalid numbers. The loose conversion is a bit too loose IMO.

Edited April 22, 2017 by czardas