feat(operators): Add AND, OR, and NOT bitwise operators

[asauzeau]

Summary

Add AND (&), OR (^) and NOT (~) bitwise operators. See #1386.

'|' token was already used for the merge operator so I chose another token for the not operator, but it's not ideal since it's usually used for XOR operator.

Change Type

• Bug fix
• New feature
• Non-functional (chore, refactoring, docs)
• Performance

Is this a breaking change?

• Yes
• No

How did you test this PR?

Tests are included.

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on
  our guidelines.
• No. A maintainer will apply the "no-changelog" label to this PR.

Checklist

• Our CONTRIBUTING.md is a good starting place.
• If this PR introduces changes to LICENSE-3rdparty.csv, please
  run dd-rust-license-tool write and commit the changes. More details here.
• For new VRL functions, please also create a sibling PR in Vector to document the new function.

[pront]

Nice addition. Did you have a chance to run the fuzzer as well?

[asauzeau]

Yes I tested it for about ten minutes and didn't experience any crashes. I'll try to run it longer.

[pront]

'|' token was already used for the merge operator so I chose another token for the not operator, but it's not ideal since it's usually used for XOR operator.

Did you mean you chose ^ for the OR operator? We want to reserve ^ as the XOR operator.

I don't see an easy solution around this. Perhaps we could replace | with something like ++ and then use | for OR but that is a multi-step process. Ideally we would also provide a script for users to update their programs.

[asauzeau]

Okay indeed, it seems like a good idea to rename the merge operator using ++, so that | can later be reused for the bitwise OR operator, allowing us to keep ^ for the XOR operator.

So I'm I supposed to follow the cycle of this document and for now just “depreciate” the merge operator | and indicate that it will be renamed ++ in a future release?

Ideally we would also provide a script for users to update their programs.

Good idea.

[pront]

So I'm I supposed to follow the cycle of this document and for now just “depreciate” the merge operator | and indicate that it will be renamed ++ in a future release?

Yes, that sounds like a reasonable plan. This reminds me we need a similar policy that lives in the VRL repo. BTW, I mentioned ++ because it seems like a natural fit, but didn't think too hard. There might be an even better option.

[asauzeau]

BTW, I mentioned ++ because it seems like a natural fit, but didn't think too hard. There might be an even better option.

Initially I had in mind <> as an alternative, but that might be less intuitive. If there are no plans to add increment and decrement operators, I also think we could opt for ++ for the merge operator.

[pront]

Hmm, on one hand ++ seems a natural candidate for those who come from Scala/Haskell, on the other hand, I cannot rule out introducing increment/decrement by 1 later. Let's do <>.

We could also have <<< right-biases merge and >>> left-biased merge.

[sbalmos]

Just randomly reviewing the issue list here... Might I suggest .+ for the merge operator instead? This would sort of keep convention with . being the object path accessor. More importantly, <> is a historical alternative for !=, namely in Microsoft languages (SQL Server SQL, VB, etc).

It also occurs to me that the current merge-assign operator, |=, would also need to change, which leads me to suggest .=. That pattern is at least known in a few languages for element/field-level merging. Admittedly it's more well-known in some languages for string concatenation. But precedent is there.