Honestly, I'm not so certain I'd like to see such a command added to the language. All a SELECT CASE is, is a series of IF.. THEN statements, which use the same base condition to check against. Heck, when translated into the c-code, which is compiled, they're translated into IF THEN ELSE type statements.
Let's take a quick look at some QB64 code, and its translated output:
if ((qbs_cleanup(qbs_tmp_base,qbs_equal(__STRING_X,qbs_new_txt_len("A",1))))||new_error){
goto sc_1_end;
}
if ((qbs_cleanup(qbs_tmp_base,qbs_equal(__STRING_X,qbs_new_txt_len("B",1))))||new_error){
goto sc_1_end;
}
if ((qbs_cleanup(qbs_tmp_base,qbs_equal(__STRING_X,qbs_new_txt_len("C",1))))||new_error){
goto sc_1_end;
}
sc_1_end:;
As you can see, all those SELECT CASE statements are translated into nothing more than a series of IF statements, with a GOTO making them skip all the irrelevant sections.
Adding a _BREAK command into the code would be as simple as translating that break into another one of those GOTO statements. (goto sc_1_end, in this case)
My issue is, if we start making commands dedicated to this type of purpose, how many other commands are we going to need to add the same functionality in other functions?
IF x = 3 then
'do some stuff
'if something triggers then _EXIT IF??
There's a reason why the language has GOTO in it. Sometimes, it's simply the tool we need to make use of, without having to have customized keywords which do nothing more than replicate its functionality.
One problem I foresee, if EXIT _CASE is implemented, is how it might interact with SELECT EVERYCASE.
SELECT EVERYCASE basically translates the code the same as above, but without those GOTO statements between each IF condition.
If we have code like the following, how is it supposed to act?
SELECT EVERYCASE x$
CASE "A"
z = z + 1
IF z = 3 then EXIT SELECT
y = y + 2
CASE "B"
CASE "C"
END SELECTNow, is that EXIT SELECT supposed to exit all the way to the END SELECT? If we goto our existing label, that's where it'd jump to.
OR is it supposed to exit down to the CASE "B" statement? If so, then all SELECT CASE statements will need to have labels added to each of them, so we can jump to the proper one.
Both options would be simple enough to implement, if folks really want to add them (personally, I don't think they're necessary), but I'd suggest if added, and if it's supposed to work as the second option (jump to the next CASE), then why not make two commands? EXIT SELECT which jumps all the way to the end of the SELECT CASE, and an EXIT CASE, which jumps down to the next CASE statement instead.
Another thing to consider, if we're going to be jumping between CASES... How would that work with a CASE ELSE?
Implementing any changes might not be quite as simple as it first seems, as there's a lot of little things to keep in mind and account for, with the command, to keep the program/logic flow proper.
