This change is backwards compatible because it's possible that someone has used variables that contain : in their name like ${FOO:BAR}. If we always consider the part after the colon to be the type, then such usage won't work anymore. One possibility is checking is that part a recognized type, but there's still a risk that someone has a variable like ${MY:LIST}. It would naturally be safest to deprecate using colons in variable names first, but that would mean that the actual conversion support needed to wait until RF 3.3. In my opinion the risk for this change causing problems is small enough and benefits of the new syntax are big enough to do the change already in RF 3.2.

If this enhancement is implemented, it makes issue #2699 pretty useless. The more I think about it, the more I like this one compared to that one. Mainly because this has so many other benefits than just supporting lists/dicts with embedded arguments.

The main questions is, when could this be implemented. RF 3.2 starts to be so much overdue that this issue cannot fit it unless someone else is interested to look at implementing it. RF 3.3. is possible, but also there are so many other high priority features that external help would be highly appreciated.

We have PR #3385 implementing this so I'll add this tentatively to RF 3.2 scope. That release is so much overdue that I cannot make promises will this issue make into it, though.

Unfortunately this is too much work for the already overdue RF 3.2.

I think expected type is only needed when variable is receiving a value. This is special case.
I propose that the type should be outside of the body. So we extend current syntax instead of making a rather backwards incompatible change
Like this ${mynumber}:int 3 and not ${mynumber:int} 3

And ignore type info on embedded keyword var syntax or escape it.

I'd prefer the ${name: type} syntax over ${name}: type for these reasons:

• Looks better to my eye.
• Easier to implement as the logic to find variables doesn't change.
• Allows using types with embedded arguments. This is pretty important.
• Works well also when assigning variable based on kw return value.

As I already commented above, I don't consider backwards compatibility problems that big. Probably best to allow still using colons in names like ${foo:bar} but perhaps that should be deprecated. Alternatively we could require the separator to be : i.e. a colon followed by a space.

This conversion is also a bit different from static typing although the syntax points to that.

Would this converter be a property of the variable or an external thing? How should each of these behave?

*** Variables ***
${myvar: int}   3

*** Keywords ***
Doing something
  ${myvar} =   Calling Library Keyword

Doing something differently
  ${myvar: str} =    Calling Batman

Doing the usual
  ${myvar: int} =    Calling Mom

It would just be a converter. Creating a variable like ${x:int} would mean converting the value to an integer but ${x} could later be assigned to other type.

User Guide documentation still missing and the code can be enhanced a bit as well.

Using non-string variables from the command line had a separate issue #2946. That has now been implemented as well and this conversion functionality needs to be documented as part of this issue.

The current syntax to create an embedded argument with both a type and a custom regexps is ${name:pattern: type}. This is somewhat inconsistent with the general variable type syntax ${name: type} and even more inconsistent with the CLI variable type syntax name: type:value (#2946). I believe we should change the syntax to ${name: type:pattern} and others on the #devel channel agreed.

I enhanced documentation in 30d87e4. Unfortunately it isn't possible to see generated docs before the final release is out, but here are links to the most relevant places in the documentation source that ought to render somewhat well:

• Variable type conversion
• Argument conversion with user keywords
• Argument conversion with embedded arguments
• Loop variable conversion

All kind of comments about the docs are welcome and can be written either to here to a thread I'll start about this on the #devel channel on our Slack. This issue can anyway be considered done already now.