switch bug Topic is solved

Report problems with documented functionality
aliztori
Posts: 117
Joined: 19 Jul 2022, 12:44

switch bug

Post by aliztori » 26 Oct 2022, 15:50

This Not Working

Code: Select all

    v := 00
    Switch v
    {
        case "0": ToolTip, 1
        case "00": ToolTip, 2
    }
 return
but This is Work

Code: Select all

v := 00
if (v =  "0")
   ToolTip, 1
else if (v =  "00")
   ToolTip, 2

 return


niCode
Posts: 279
Joined: 17 Oct 2022, 22:09

Re: switch bug

Post by niCode » 26 Oct 2022, 18:09

In the first example,

Code: Select all

case "0"
is comparing to a string but you set the v variable to an integer.

User avatar
boiler
Posts: 16767
Joined: 21 Dec 2014, 02:44

Re: switch bug

Post by boiler » 26 Oct 2022, 18:51

niCode wrote: In the first example,

Code: Select all

case "0"
is comparing to a string but you set the v variable to an integer.
Then explain the result of the second script.

niCode
Posts: 279
Joined: 17 Oct 2022, 22:09

Re: switch bug

Post by niCode » 26 Oct 2022, 19:11

boiler wrote:
26 Oct 2022, 18:51
Then explain the result of the second script.
Good point. I was so focused on seeing one wrong thing, I assumed that was all there was to it.

aliztori
Posts: 117
Joined: 19 Jul 2022, 12:44

Re: switch bug

Post by aliztori » 27 Oct 2022, 09:12

niCode wrote:
26 Oct 2022, 18:09
In the first example,

Code: Select all

case "0"
is comparing to a string but you set the v variable to an integer.
What should I have done?

aliztori
Posts: 117
Joined: 19 Jul 2022, 12:44

Re: switch bug

Post by aliztori » 27 Oct 2022, 09:15

boiler wrote:
26 Oct 2022, 18:51
niCode wrote: In the first example,

Code: Select all

case "0"
is comparing to a string but you set the v variable to an integer.
Then explain the result of the second script.
but i think that's bug you mean switch use inStr ?

aliztori
Posts: 117
Joined: 19 Jul 2022, 12:44

Re: switch bug

Post by aliztori » 27 Oct 2022, 09:22

See, this can completely break the script

Code: Select all

df := 00

	Switch (001234)
	{
		Case "01234": ToolTip, 1
		Case "001234": ToolTip, 2
	}

aliztori
Posts: 117
Joined: 19 Jul 2022, 12:44

Re: switch bug

Post by aliztori » 27 Oct 2022, 09:24

See, this can completely break the script

Code: Select all

df := 001234

	Switch (df)
	{
		Case "01234": ToolTip, 1
		Case "001234": ToolTip, 2
	}
tooltip,1 Shows -_-

But this example works With if

User avatar
boiler
Posts: 16767
Joined: 21 Dec 2014, 02:44

Re: switch bug

Post by boiler » 27 Oct 2022, 09:50

aliztori wrote:
27 Oct 2022, 09:15
but i think that's bug you mean switch use inStr ?
No, I was pointing out to niCode that his answer didn't explain why the other case acts differently, so I was agreeing with you that it is a bug or at least an inconsistency.

guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: switch bug

Post by guest3456 » 27 Oct 2022, 10:59

boiler wrote:
27 Oct 2022, 09:50
so I was agreeing with you that it is a bug or at least an inconsistency.
+1


lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: switch bug

Post by lexikos » 27 Oct 2022, 22:40

When posting a bug report, code to reproduce the issue, a description (even a brief one) of your expectations and what results you are getting should be the bare minimum that you provide. This bug report is lacking two of those things - arguably all of them, if you consider that the tooltip never displays because the script exits immediately.

I think that mixing both unquoted literal numbers and quoted literal strings within the same switch not only fails to show your intent (do you intend numeric or non-numeric evaluation?), but might indicate that you are not considering that a distinction needs to be made in the first place. Instead, it seems you are expecting the language to implicitly understand what you are trying to do despite mixed signs of intent.

One might expect switch (00)..case "0": to be consistent with if (00 = "0"), but these values are evaluated individually, at different times. Consider this:

Code: Select all

a := 00
b := "0"
MsgBox % (a = b) ; 1
Which behaviour is correct or most intuitive for Switch cannot be decided based purely on how the expression operators behave. Inconsistency within the type system is a fundamental problem of v1, not just Switch.

Ignoring how the switch value is expressed, it would be reasonable to assume that case "0": is intended to compare a string, since a number should have been expressed as case 0:. It doesn't currently work that way because Switch was primarily designed for v2, where the types of the input values have less ambiguity.

Changing Switch to always perform string comparison for case "0": seems to be the simplest solution, although it would perpetuate a legacy quirk of v1 that does not apply to v2 (where (0 = "00") and v := 00..switch v..case "0": use numeric comparison because v is a pure number). Changing it to behave exactly as in v2 would not be feasible because it would depend on broader changes to the type system that have a high risk of breaking scripts. Since the current behaviour is already inconsistent with v2 and is less flexible, perhaps the simple solution is acceptable.

On the other hand, back-porting the CaseSense parameter of Switch would provide a clear and unambiguous way to ensure that all of the values are compared as strings.


Of less importance, the current documentation of Switch in v1 does not specify how the comparisons are made. The current behaviour is compliant with the documentation.

aliztori
Posts: 117
Joined: 19 Jul 2022, 12:44

Re: switch bug

Post by aliztori » 28 Oct 2022, 06:14

lexikos wrote:
27 Oct 2022, 22:40
When posting a bug report, code to reproduce the issue, a description (even a brief one) of your expectations and what results you are getting should be the bare minimum that you provide. This bug report is lacking two of those things - arguably all of them, if you consider that the tooltip never displays because the script exits immediately.

I think that mixing both unquoted literal numbers and quoted literal strings within the same switch not only fails to show your intent (do you intend numeric or non-numeric evaluation?), but might indicate that you are not considering that a distinction needs to be made in the first place. Instead, it seems you are expecting the language to implicitly understand what you are trying to do despite mixed signs of intent.

One might expect switch (00)..case "0": to be consistent with if (00 = "0"), but these values are evaluated individually, at different times. Consider this:

Code: Select all

a := 00
b := "0"
MsgBox % (a = b) ; 1
Which behaviour is correct or most intuitive for Switch cannot be decided based purely on how the expression operators behave. Inconsistency within the type system is a fundamental problem of v1, not just Switch.

Ignoring how the switch value is expressed, it would be reasonable to assume that case "0": is intended to compare a string, since a number should have been expressed as case 0:. It doesn't currently work that way because Switch was primarily designed for v2, where the types of the input values have less ambiguity.

Changing Switch to always perform string comparison for case "0": seems to be the simplest solution, although it would perpetuate a legacy quirk of v1 that does not apply to v2 (where (0 = "00") and v := 00..switch v..case "0": use numeric comparison because v is a pure number). Changing it to behave exactly as in v2 would not be feasible because it would depend on broader changes to the type system that have a high risk of breaking scripts. Since the current behaviour is already inconsistent with v2 and is less flexible, perhaps the simple solution is acceptable.

On the other hand, back-porting the CaseSense parameter of Switch would provide a clear and unambiguous way to ensure that all of the values are compared as strings.


Of less importance, the current documentation of Switch in v1 does not specify how the comparisons are made. The current behaviour is compliant with the documentation.

i just use wrong code
byt bug still exist

Code: Select all

df := 001234

	Switch (df)
	{
		Case "01234": ToolTip, 1
		Case "001234": ToolTip, 2
	}

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: switch bug

Post by lexikos » 28 Oct 2022, 19:08

@aliztori You already posted that code, and it is no more or less wrong than the original code. Everything I said still stands.

To summarize my previous post:
  • Using both literal numbers and literal strings is irrational. You are sending mixed signals to the interpreter and anyone who reads the code.
  • I acknowledged the issue and explained the cause and possible future solutions.
  • The current behaviour is compliant with the documentation. It is not a bug.

aliztori
Posts: 117
Joined: 19 Jul 2022, 12:44

Re: switch bug

Post by aliztori » 04 Nov 2022, 06:12

lexikos wrote:
27 Oct 2022, 22:40
When posting a bug report, code to reproduce the issue, a description (even a brief one) of your expectations and what results you are getting should be the bare minimum that you provide. This bug report is lacking two of those things - arguably all of them, if you consider that the tooltip never displays because the script exits immediately.

I think that mixing both unquoted literal numbers and quoted literal strings within the same switch not only fails to show your intent (do you intend numeric or non-numeric evaluation?), but might indicate that you are not considering that a distinction needs to be made in the first place. Instead, it seems you are expecting the language to implicitly understand what you are trying to do despite mixed signs of intent.

One might expect switch (00)..case "0": to be consistent with if (00 = "0"), but these values are evaluated individually, at different times. Consider this:

Code: Select all

a := 00
b := "0"
MsgBox % (a = b) ; 1
Which behaviour is correct or most intuitive for Switch cannot be decided based purely on how the expression operators behave. Inconsistency within the type system is a fundamental problem of v1, not just Switch.

Ignoring how the switch value is expressed, it would be reasonable to assume that case "0": is intended to compare a string, since a number should have been expressed as case 0:. It doesn't currently work that way because Switch was primarily designed for v2, where the types of the input values have less ambiguity.

Changing Switch to always perform string comparison for case "0": seems to be the simplest solution, although it would perpetuate a legacy quirk of v1 that does not apply to v2 (where (0 = "00") and v := 00..switch v..case "0": use numeric comparison because v is a pure number). Changing it to behave exactly as in v2 would not be feasible because it would depend on broader changes to the type system that have a high risk of breaking scripts. Since the current behaviour is already inconsistent with v2 and is less flexible, perhaps the simple solution is acceptable.

On the other hand, back-porting the CaseSense parameter of Switch would provide a clear and unambiguous way to ensure that all of the values are compared as strings.


Of less importance, the current documentation of Switch in v1 does not specify how the comparisons are made. The current behaviour is compliant with the documentation.
thanks dude but
You mean what should I do?
I have many reviews in my script,
like if df = 00010
or if df = 011010
or if df = 0000
and ...
should I use if and else if in all of them?

User avatar
boiler
Posts: 16767
Joined: 21 Dec 2014, 02:44

Re: switch bug

Post by boiler » 04 Nov 2022, 07:14

Since the leading zeros are apparently important to you, store them and compare them all as literal strings (i.e., with quotes around them), not as literal numbers as you are showing.

safetycar
Posts: 435
Joined: 12 Aug 2017, 04:27

Re: switch bug

Post by safetycar » 04 Nov 2022, 09:01

boiler wrote:
04 Nov 2022, 07:14
Since the leading zeros are apparently important to you, store them and compare them all as literal strings (i.e., with quotes around them), not as literal numbers as you are showing.
I thought the same but I tried it and didn't work, that's a fix for v2, not for v1.

Code: Select all

    v := "00"
    Switch v
    {
        case "0": Msgbox 1 ; v1
        case "00": Msgbox 2 ; v2
    }

User avatar
boiler
Posts: 16767
Joined: 21 Dec 2014, 02:44

Re: switch bug

Post by boiler » 04 Nov 2022, 09:05

You can use the workaround that was suggested by someone in the other thread:

Code: Select all

    v := "00"
    Switch "|" v
    {
        case "|0": Msgbox 1
        case "|00": Msgbox 2
    }

guest3456
Posts: 3454
Joined: 09 Oct 2013, 10:31

Re: switch bug

Post by guest3456 » 04 Nov 2022, 09:57

aliztori wrote:
04 Nov 2022, 06:12
thanks dude but
You mean what should I do?
I have many reviews in my script,
like if df = 00010
or if df = 011010
or if df = 0000
and ...
should I use if and else if in all of them?
either use the workaround boiler posted
or
use ifelseif
or
wait for lexikos to fix the string case as he mentioned
or
use ternary operator:

Code: Select all

    v := "00"

    (v = "0") ? MsgBox("1")
    : (v = "00") ? MsgBox("2")

    return

    MsgBox(str) {
      MsgBox, %str%
    }
Last edited by guest3456 on 04 Nov 2022, 10:08, edited 1 time in total.


MancioDellaVega
Posts: 83
Joined: 16 May 2020, 12:27
Location: Italy

Re: switch bug

Post by MancioDellaVega » 04 Nov 2022, 10:02

this works too...

Code: Select all


    v := "000"
    Switch 1 
    {
        case (v="000"): Msgbox 3
        case (v="0"): Msgbox 1
        case (v="00000"): Msgbox 5
        case (v="00"): Msgbox 2
        case (v="0000"): Msgbox 4
    }


Courses on AutoHotkey

lexikos
Posts: 9553
Joined: 30 Sep 2013, 04:07
Contact:

Re: switch bug  Topic is solved

Post by lexikos » 01 Dec 2022, 03:36

This produces "2" with v1.1.36.00.

Code: Select all

v := 00
switch v
{
    case "0": MsgBox 1
    case "00": MsgBox 2
}

Post Reply

Return to “Bug Reports”