Pekka Klärck

Could you clarify the need in a bit more detail? `Run Keyword` doesn't do much logging on INFO or DEBUG level even now.

The problem implementing this is that on the execution side there currently isn't any place where we could call `start/end_keywords` so that they would get data and result objects similarly...

This is, very unfortunately, too much work for RF 4.0. Recent model changes (#3749) have improved the code related to this a lot but also shown that there's still quite...

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...

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...

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...

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

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....

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.

Yeah, `${var}: type` syntax has its benefits. Need to look at all pros and cons when we actually start to implement this. Due to the work needed to get all...