Allow "type guards" in VRL

[jszwedko]

I believe we've discussed this in other places before as well, but it came up again in vectordotdev/vector#9406 where a user expected that if they used is_string() that VRL would be able to determine that the argument thereafter was a string if the rest of the expression only executed if is_string was true.

Specifically, they had:

is_string(.message) && !contains(.message, s'test')

But you could also imagine this with if conditions:

if is_string(.message) {
 !contains(.message, s'test')
} else {
  false
}

I'm not 100% sold on if we want to do this, but opening for discussion.

[JeanMertz]

see also: vectordotdev/vector#5261 (comment)

[myndzi]

(Just to leave a comment reflecting my use case)

I think this kind of expression shortcutting is both common and expected in many contexts. However, the real value is in the separation of concerns. The example in the OP is good:

is_string(.message) && !contains(.message, s'test')

This is essentially: "if the message conforms to my expectations, then evaluate some expression that relies on those expectations", where these two parts are decoupled and explicitly defined. Relying on coercion and failure handling instead makes things messy or unclear (at least, it certainly is less clear to me, being less familiar with the intricate details of VRL).

From discord, for example:

So, if you want to pass a condition if a field exists, and it's a string, and it contains foo, then this would work:

exists(.message) && contains(string!(.message), "foo")

This can still fail at runtime, if .message isn't a string, but it'll never fail if the field is missing.

So this solution is both more verbose and still not complete and correct. A solution like contains(to_string!(.message), "foo") is also unfortunate: if .message is a number for some reason, and that number becomes a string ("42"), there are cases where it might unexpectedly match (the match text being numeric in nature, for example).

All in all, given that properties which don't exist are "null", then the expression is_string(.message) && .... checks both existence and type, which allows you to cleanly express the actual thing you care about and also dictate whether a non-conforming event passes or fails the condition quite naturally.