Are you looking similar what is proposed in the #2957 ? If you aren't, could you explain what you are actually want?

#2957 covers lists and dicts, but supporting also other base types, mainly numbers and Booleans, could be handy as well. Possible solutions:

1. Separate prefixes such as INT__ similarly as Support providing list and dictionary variables from command line. #2957 proposes LIST__.

2. Generic prefix to mean that the value should be evaluated in Python. Could be something like EVAL__ or PYTHON__.

3. Some other way to specify the type. Syntax inspired by function annotations line --variable VAR:int:42 could work. Should use the same with lists and dicts as well.

4. Support Robot's variables in values. That would allow e.g. integers like --variable 'VAR:${42}' and also support possible useful usages like -v VAR:foo -v VAR2:${VAR}bar.

Especially if we go with the option 3, we should use the new type conversion code to handle the values. We could then consider using the same syntax in the test data as well:

*** Variables ***
${VAR:int}         42
${V2:list}         ['foo', 'bar']

I closed #2957 as a duplicate of this issue. If we add support for non-string variable values from the CLI, we definitely should support lists and dicts as well as numbers and Booleans.

Thinking this again and looking at the possible solutions I listed above my current thinking is that:

• Prefixes like INT__ and LIST__ or the generic EVAL__ are all pretty ugly.

• Postfix used like --variable VAR:int:42 look much better. Supporting them in the Variables section the test data as proposed the comment above would be super useful as well but should get its own issue.

• Being able to use variables on the CLI like --variable 'VAR:${42}' could be useful as well. It wouldn't support lists/dicts, though, but being able to refer to earlier variables like -v HOST:1.2.3.4 -v 'URL:http://${HOST}/example' would be handy.

I'd say we should go with the <name>:<type>:<value> design. For backwards compatibility reasons we cannot make the <type> part mandatory, though, and should handle situation where the value contains colons like -v URL:http://.... Basically we should use the type information only if we recognize the part between colons.

I also like the <name>:<type>:<value> syntax and give my vote for it.

The more I think about this, the more I like the <name>:<type>:<value> syntax. It would also work great with the proposed variable/argument type conversion in test data (#3278). These issues should probably be designed and also implemented together. Especially the latter is too big for RF 3.2 (unless we get external help), and I think this one should be moved from its scope as well.

Variable type conversion has been implemented and will be part of RF 7.3 (#3278). When designing it with @aaltat , we discussed also about command line variables but later forgot about them. Let's add that support in RF 7.4.

It was earlier discussed that separating the type from the name with a colon like syntax --variable x:int:42 would work well. In the data we use the colon as well so it would be consistent, but in the data a space is mandatory after the colon like ${x: int}.

I believe we should use the colon also on the command line, but there are some design decisions to be made:

1. Should we require a space after the colon also on the command line? It requires quoting the value like -v "x: int:42" which is a bit inconvenient, but not that big a problem.
2. Because we use the colon as the value separator and values themselves can have colons, it is possible that someone has used something like -v name:value:with:colons. Requiring a : as the type separator would avoid problems with that, but there would still be problems if someone would have use -v "name: starting space:and:colons. Is this so unlikely that we could require them to add a type like -v name: str: starting space:and:colons?
3. An alternative would be parsing -v xxx:yyy:zzz syntax so that it would be considered to have a type only if the yyy part would be a valid type. Also that's not totally backwards compatible, because someone could have used -v x:int:xxx with int:xxx being a literal value. This syntax also would have an annoying problem that possible future types could break existing variable usages if the new type would match that's currently used as a literal value. I believe that is too big a problem to make this a good approach.

The x:int42 would be easiest for usage point of view, but the risk of its being backwards incompatible can be high. The ”x: in:42” would be safer and consistent because it is same syntax as in test data side. Quotation makes it less user friendly. If with history background, I would go with first option, but because history exists, then I would go with spaces

I prototyped this and this turned out to be very easy to implement using syntax name: type:value that, as discussed above, ought to be mostly backwards-compatible. I consider this so important part of the overall variable type conversion that I'll add this to RF 7.3 and create rc3 once this is ready.

Documenting this will be done as part of documenting #3278.