Return values aren't exposed via the result model directly. One reason is that return values can be huge and storing them could waste a lot of memory and disk space. Return values are logged, though, and that automatic message can be inspected in the log_message method. Due to the values potentially being huge, that message only contains the beginning of the result, though. It's also possible to log the whole value explicitly, but then you need to make changes to the data. Logged messages are also always strings, which is likely a problem if the return value is something else.

I can see that it would be convenient to have a direct access to return values somehow, and being able to change the return value could be useful too. In addition to that, it could be nice to a direct access to used arguments and to be able to modify them. The main question is, how should these APIs work?

Hi Pekka @pekkaklarck

You do have a keyword.Result class, and right now it holds everything except an actual result. "They could be huge" is a weak argument against it; if it's huge, so what? The Puppeteer process consumes a lot more memory than 99.99% of keyword results would. I only have access to them when the keyword is returning their value inside the listener, so I can collect, modify, and probably assign them to a variable. Garbage collect them right away if you're so concerned about memory.

For my use case, I would be fine if the variable ${previous_keyword_result} were created after each keyword run; it will simplify a lot of code. So this:

${title} = Get Title
Should Match  'ok' ${title}

Will became:

Get Title
Should Match  'even better' ${previous_keyword_result}

A little like bash is doing with $?, hacky, less descriptive but works.