One of the (main) goals of the DSL was that simple things should be simple. However, as @bmesuere pointed out, requiring !v for string and object return values is not obvious behaviour, nor it is easily explainable (as booleans, numbers and lists don't need it).
Some possible solutions include:
Introducing a new key, return_value, which would replace return: !v: the value would thus always be a literal string.
Introducing a new key, return_x, which would revert to the previous behaviour of return_raw, but with a better name.
Introducing a new tag for Python-strings, e.g. !p or !ast or !tested, thus the reverse of the current behaviour. Values are literal by default, and our Python-like syntax if annotated with a tag.
Always mandating Python-like syntax. While consistent, this introduces overhead for simple cases.
Currently, I believe a single return key return with a new tag !ast (not 100% on the name yet) would satisfy our requirements:
By default, values are literal. This is consistent with all return data types, and probably the most used scenario.
The !ast could be explained to indicate the return value is special, which it is (as we already have this explanation to say why the Python-like syntax exists in return values).
Pinging @pdawyndt as the current situation was our previous conclusion.
One of the (main) goals of the DSL was that simple things should be simple. However, as @bmesuere pointed out, requiring
!v
for string and object return values is not obvious behaviour, nor it is easily explainable (as booleans, numbers and lists don't need it).Some possible solutions include:
return_value
, which would replacereturn: !v
: the value would thus always be a literal string.return_x
, which would revert to the previous behaviour ofreturn_raw
, but with a better name.!p
or!ast
or!tested
, thus the reverse of the current behaviour. Values are literal by default, and our Python-like syntax if annotated with a tag.Currently, I believe a single return key
return
with a new tag!ast
(not 100% on the name yet) would satisfy our requirements:!ast
could be explained to indicate the return value is special, which it is (as we already have this explanation to say why the Python-like syntax exists in return values).Pinging @pdawyndt as the current situation was our previous conclusion.