Skip to content

Change VAR syntax so that using it without value promotes variable to specified scope #5369

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
kstine opened this issue Mar 16, 2025 · 4 comments
Open

Change VAR syntax so that using it without value promotes variable to specified scope #5369

kstine opened this issue Mar 16, 2025 · 4 comments
Labels
backwards incompatible effort: medium priority: high
Milestone
v8.0

Comments

@kstine
Copy link
Contributor

kstine commented Mar 16, 2025 •
edited
Loading

With regards to VAR syntax and Set Variable there are a few behaviors that do not functionally match.

My observation is that the VAR syntax cannot change an existing variable's scope.

This is a known RF pattern:

${SOME_FUTURE_SUITE_VARIABLE}     Get Time
Set Suite Variable    ${SOME_FUTURE_SUITE_VARIABLE}

In order to so the same thing:

${SOME_FUTURE_SUITE_VARIABLE}     Get Time
VAR   ${SOME_FUTURE_SUITE_VARIABLE}    ${SOME_FUTURE_SUITE_VARIABLE}     scope=SUITE

Quoted from Pekka:

VAR ${X} scope=suite

not working the same way as

Set Suite Variable ${X}

is bad design and needing to use

VAR ${X} ${X} scope=suite

This:

VAR ${X}

creates a variable with an empty string as its value.

The change would backwards incompatible.

We could deprecate that behavior in RF 7.3 and require using:

VAR ${X} ${EMPTY}

Then later, possibly already in RF 8, we could change the syntax to match Set Suite Variable.

Here is some example code:

*** Settings ***
Documentation    Examples of setting variables.
Suite Teardown    Suite Teardown


*** Test Cases ***
Set Variable Test
    ${GET_TIME_SET}     Get Time
    Set Suite Variable    ${GET_TIME_SET}

VAR Syntax Test - Example 1
    ${GET_TIME_ONE}    Get Time
    VAR    ${GET_TIME_ONE}    scope=SUITE

VAR Syntax Test - Example 2
    ${GET_TIME_TWO}    Get Time
    VAR    ${GET_TIME_TWO}    ${GET_TIME_TWO}    scope=SUITE    


*** Keywords ***
Suite Teardown
    Log    GET_TIME_SET: ${GET_TIME_SET}    CONSOLE
    Log    GET_TIME_ONE: ${GET_TIME_ONE}    CONSOLE
    Log    GET_TIME_TWO: ${GET_TIME_TWO}    CONSOLE

A thought:

What if there was a syntax for setting scope of a variable?

${SOME_FUTURE_SUITE_VARIABLE}     Get Time
SET    ${SOME_FUTURE_SUITE_VARIABLE}    scope=suite
@kstine
Copy link
Contributor Author

kstine commented Mar 16, 2025

Link to playground of example: VAR examples

@MarcinGmurczyk
Copy link
Contributor

Like the idea, same issue reported by me some time ago :)
#5105

@pekkaklarck
Copy link
Member

As the quote in the description explains, I agree that the current behavior is a design mistake and should be changed. Due to backwards compatibility reasons we need to deprecate it first, though, but if we do that in RF 7.3, it ought to be fine to change the syntax in RF 8.0.

I think I had noticed #5105 submitted by @MarcinGmurczyk at some point but forgot about it. We now need to decide which one to keep open which to close as a duplicate. I typically close the latter one in this kind of cases, but this issues seems to have a bit more information, including a playground link, so I think I'll close the earlier one. It shouldn't really matter anyway.

@pekkaklarck pekkaklarck changed the title Update VAR syntax to behave the same as Set <scope> Variable Chanve VAR syntax so that using it without a value propotes vairable to specified scope Mar 27, 2025
@pekkaklarck pekkaklarck added this to the v8.0 milestone Mar 27, 2025
@pekkaklarck pekkaklarck marked this as a duplicate of #5105 Mar 27, 2025
@pekkaklarck pekkaklarck mentioned this issue Mar 27, 2025
Closed
@pekkaklarck pekkaklarck changed the title Chanve VAR syntax so that using it without a value propotes vairable to specified scope Change VAR syntax so that using it without value promotes variable to specified scope Mar 27, 2025
@pekkaklarck
Copy link
Member

pekkaklarck commented Mar 27, 2025 •
edited
Loading

Things to decide:

  1. How to handle VAR ${x}? Should it continue to create a local variable with an empty string as its value, should it "promote" ${x} to the local scope (what if ${x} doesn't exist?) or should it be an error? This still creating ${x} with an empty string as its value would avoid backwards compatibility issues in the common case and would feel pretty natural, but would it be too inconsistent if VAR ${x} scope=SUITE works differently?
  2. How to handle VAR @{x}? I believe it should create a variable with an empty list as its value like it does now. Creating an empty list is a relatively common need and avoiding the need to use @{EMPTY} would be good. I even believe that VAR @{x} scope=SUITE should behave like that and we should promote variables only when using ${x} syntax.

Once we agree how we want this syntax to work in all cases, I'll submit a separate issue about deprecating the old syntax in RF 7.3 (or RF 7.4 if we cannot agree on this soon). This issue now tracks the eventual syntax change in RF 8.

@pekkaklarck pekkaklarck mentioned this issue May 20, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
backwards incompatible effort: medium priority: high
Projects
None yet
Milestone
v8.0
Development

No branches or pull requests
3 participants
@pekkaklarck @kstine @MarcinGmurczyk