EQL: Remove (was Deprecate) = in favor of == for equality checks

[costin]

A topic that was raised in #61883 (comment) is deprecating usage of = when doing equality checks.
EQL does use = for assignments so using it for equality checks instead of == is potentially confusing (is it an assignment or an equality check?).
It would be good to get some numbers on the usage to see how often this occurs.
Based on that we can decide whether to go with a safe route (deprecation-only with removal later down the road) or straight removal.

[elasticmachine]

Pinging @elastic/es-ql (:Query Languages/EQL)

[jrodewig]

As a note for consideration: Neither the Python nor the ES implementation document = as an equality operator.

Python: https://eql.readthedocs.io/en/latest/query-guide/basic-syntax.html#conditions
ES: https://www.elastic.co/guide/en/elasticsearch/reference/master/eql-syntax.html#eql-syntax-conditions

Unless usage is high, we could potentially treat this as a bug and just remove it.

[rw-access]

Agreed. Usage of = for equality comparisons was in a gray area. It was supported out of convenience and flexibility, but never documented. This was a bit of a safety net.

We should continue to leave a single = for the maxspan= and also underdocumented fork= syntax. Similarly, I don't think there are any examples of maxspan==1m.

And of course, in both cases, I think we should continue to accept both forms in the grammar, but take the usual approach of raising a custom error message to say it's no longer supported.

Here are the usage numbers rules in our Endgame rules repo, but we tend to conform to the same convention and have PR review, so ours will be biased towards ==. In the wild, I think the usage of = is more common than this, but if we have a helpful error message, we can at least nudge users on to the right path.

• 19 =
• 1201 ==

[astefan]

I agree with completely removing the single equals (=) option, even more if this was never documented and was supported just as a convenience alternative. Keeping both around leaves room for ambiguities and is not necessary (equality should refer to a single operator). I do also want to remove it without any deprecation or error messages being logged since:

• in ES ecosystem if a feature is not documented then it is not officially supported, thus it can change at any time without any warning or deprecation message
• we should have a beta/GA version as "clean" as possible, without ambiguities in the language spec since these tend to change very rarely to not at all afterwards. Also, our users should have a clear picture of how the language looks like before they start using EQL in production

[matriv]

I also prefer to completely remove the = and have a clear grammar before beta->GA.

[costin]

@sethpayne asked

Given that we'll be supporting runtime fields in ES soon, should we reserve = for defining these fields in EQL?

What do you have in mind. = is still being used for maxspan declaration maxspan=1m and thus whenever we have assignments. I'd like for runtime fields to be as transparent as possible.

[costin]

Thanks for the feedback folks.

Considering it's an undocumented behavior (and thus without any guarantees) used in 1.5% of the cases, let's move ahead with removing = from bool expressions without going through deprecation.

@matriv can you please look at it?

Thanks

[matriv]

master : ad5ae4d
7.x : 1e72144