RFC 7496 - 2023-02-02 - VRL Return Keyword

Add return expression to the Vector Remap Language.

Context

• #7496

Cross cutting concerns

• None.

Scope

In scope

• Adding a return expression to VRL.
• The return can optionally take an expression as an argument and the result of that expression will be returned.

Out of scope

• Adding new keywords for similar purposes such as drop.
• Defining semantics of keywords that are usually used for other purposes in other languages such as break.
• Implementation of return expressions inside closures.

Pain

• Aborting with changing the input cannot be easily done.
• VRL code is often unnecessarily indented because of lack of early returns.

Proposal

User Experience

• A return expression causes the VRL program to terminate, keeping any modifications made to the event.
• A return expression must be always followed by another expression, whose value will be used as the emitted event.
• The keyword cannot be used inside a closure. Trying to do that will result in a compilation error.

Implementation

• Implementation will be similar to the current abort keyword when drop_on_abort is set to false. The only difference is that the returned value will be taken from the provided expression and not from original input.
• drop_on_abort will have no effect on return calls and configuration such as drop_on_return will not be added.

Rationale

• It will be possible to write VRL with less indentation making it more readable.
• return is already a reserved word so it can be used without introducing a breaking change.

Drawbacks

• The return keyword will be given a semantic meaning that will have to be supported going forward.

Prior Art

• Most languages have a way to make early returns.
• There was no prior attempted implementation of returns in VRL to my knowledge.

Alternatives

• New keywords that are not currently a reserved keyword can be added to the language. This would, however, constitute a breaking change.
• This feature can also be rejected as it does not add any functionality that cannot be currently expressed.

Outstanding Questions

Plan Of Attack

Incremental steps to execute this change. These will be converted to issues after the RFC is approved:

• Submit a PR with implementation of returns.

Future Improvements

• Adding a drop keyword for explicit drop as an alternative to pre-configured abort for full control over passing the events to output unchanged, passing them changed, or routing them to the dropped output.
• Adding return to closures.