One obvious thing to decide is what we do with Exit For Loop and Continue For Loop keywords after BREAK and CONTINUE are implemented. I think its better to deprecate and remove them. It's better to have just one way to accomplish one thing and making BuiltIn library smaller is good as well. We should, however, wait at least until RF 5.1 before emitting deprecation warnings.

A related question is what to do with conditional variants Exit For Loop If and Continue For Loop If. They make shorter constructs than IF with BREAK or CONTINUE, but I think having just one way to break/continue is more important. We could consider some kind of inline IF structure later if shorter structures are considered important. It would then work also with RETURN.

Single line IF option would be great. The new IF syntax is soooo much better for conditional blocks than the prior Run Keyword If Run Keywords … AND … AND … AND silliness we had to do. But when you start using the new IF everywhere instead of Run Keyword If , you end up with awkwardness of IF - END’s around single lines all over the place.

I would never choose having to put … and AND stuff for blocks like it was for run keywords Nor would I want anything that only lets you put a keyword that cannot have arguments. But it would be great if IF had two syntaxes:

IF    <condition>    <keyword>   [*args]

IF    <condition>
    <whatever>
    <you>
    <want>
END

So if the IF keyword has 3+ arguments, the first syntax is automatically chosen and you can not continue to new lines without using the … continuation keyword, and you may not have more than one keyword (please no AND syntax! 🙂) and you may not nest.

I know this is not how python works but it’s not a completely made up concept either AppleScript (another keyword language) is a good example. They call this “if (simple)” and “if (compound)”. They use the pattern a lot all over too for example Tell works the same way. For a single tell statement on the same line, no end tell is required. But for a block it is required.

IMO that’s the right thing to do, Robot’s roots is a keyword language so even though it’s python based, forcing it to behave with the same pythonic rules (inconveniences) that python has when there is a more natural way to do things will make it too close to python and it looses it’s value prop of simple natural-language-like readability with a focus on telling what’s being tested and not distracting with how the test has to be written.

The above syntax to run single keyword with IF looks pretty good. Would need to think should we also support ELSE and ELSE IF and should we allow assignment:

${var} =    IF    expr    Keyword    arg    ELSE    Another Keyword

This discussion definitely needs its own issue. Could you @ericbjones submit one?

I wrote instructions to #4078 (comment) about how to get started with adding RETURN. Same instructions apply to this issue as well.

There is one open design decision related to BREAK and CONTINUE. Should it be possible to use them in a keyword that is used in a loop or should they be allowed only directly inside a loop? For example, should this pass or fail for a syntax error:

*** Test Cases ***
Example
    FOR    ${x}    IN    a    b   c
        Keyword
    END

*** Keywords ***
Keyword
    BREAK

I pretty firmly believe BREAK and CONTINUE should be allowed only directly inside a loop and the above example should cause a syntax error. A problem is that the current Exit For Loop and Continue For Loop keywords don't work like that. For example, if BREAK in the above example is replaced with Exit For Loop, the test succeeds and the loop is executed just once. Although the plan is to deprecate and eventually remove these keywords, changing their functionality would be a backwards incompatible change and we in general try to avoid them.

My current thinking is to handle this as follows:

1. Allow BREAK and CONTINUE only inside loops, not in keywords used by loops.
2. Try to implement this so that Exit For Loop and Continue For Loop behavior won't change.
3. If implementing 1. and 2. at the same time is hard, change the behavior of Exit and Continue For Loop keywords.

Notice that although I wrote "directly inside a loop" above, BREAK and CONTINUE should definitely be usable inside IF/ELSE and TRY/EXCEPT structures as long as they are inside a loop.

UPDATE: We decided to allow BREAK and CONTINUE only inside loops and to change Exit For Loop and Continue For Loop to work that way as well. The change to Exit/Continue For Loop is covered by #4185.

Initial implementation was been done by @bbpatel2001 in already merged PR #4136. Big thanks for contribution!

Things to do:

• Add acceptance tests.
• Fix using BREAK and CONTINUE with values like BREAK value. That shouldn't be allowed but currently works. This is validated already now by the parser, but the error is not propagated further. Part of this is obviously adding adequate acceptance tests.
• Disallowing using BREAK and CONTINUE when not inside FOR or WHILE. Parser doesn't allow using them directly in keyword, but it probably is possible to use wrap them into IF or TRY.
• Part of the above is deciding what to do with existing Exit For Loop and Continue For Loop keywords. I believe we should disallow them outside loops as well. That probably should get its own issue. UPDATE: This is covered by Prohibit using Exit For Loop and Continue For Loop in keywords #4185.
• Fix using BREAK and CONTINUE inside TRY/EXCEPT. Currently they aren't allowed at all.
• Fix minor issues in the PR (mainly whitespace usage).
• Update output.xml schema

This ought to be now done except for documentation that is covered by #4203. This issue can now be closed. Big thanks again for @bbpatel2001 for the initial PR!