Remove scalar/scalar comparisons

[brian-brazil]

Scalar == scalar is unlike vector == scalar and vector == vector in that it doesn't filter. To keep the language orthogonal and consistent, I propose we drop support for scalar/scalar comparisons. Any case where it would be useful should be doable via vectors.

[brian-brazil]

Another option would be to make it filter.

[juliusv]

How would it filter? By returning an empty vector? What purpose would that serve? (but removing sounds good so far)

[brian-brazil]

It'd do the same as vector/vector, return the left argument.
Hmm, if we do that we'd want to remove support for scalar/vector and only allow vector/scalar.

[brian-brazil]

A use case has appeared for filtering scalar/scalar comparisons: restricting times when alerts fire via math on time(). Accordingly let's filter and take the left argument.

[fabxc]

As complaints about breaking changes are getting louder with time, we might want to make a decision on this in the next few weeks.

[juliusv]

@brian-brazil I'm still not clear on how scalar/scalar would filter: if the return type is scalar as well, what would the return value be for something like 5 < 3? NaN?

[brian-brazil]

Hmm, yeah you'd need to make the result of scalar/scalar comparisons to be vectors for it to work - which would break other things.

That'd imply dropping support for it, and using absent({}) or maybe a one/iota/unity() function that returns a vector with a single no-label sample with value 1 for when you need to filter.

[fabxc]

Devil's advocate - would it make sense to drop scalars all together and parse a number literal as a single-element vector without labels?
Except for arguments in functions such as topk.

We'd have to allow unary expressions for vectors. Label matching simply wouldn't make sense as the label set is empty.

This would naturally solve some issues such as not being able to graph a line when you type 5.
In general that'd be more of an internal change.

[brian-brazil]

Devil's advocate - would it make sense to drop scalars all together and parse a number literal as a single-element vector without labels?

That'd require group_left/group_right on "scalar"/vector operations, which'd be too overbearing considering how common that is.

[brian-brazil]

Another thought is that a scalar/scalar comparison could return a vector, either empty or {}:left value

[brian-brazil]

To summarize, we've two options to clean this up:

• Drop support for non-filtering scalar comparisons
• Filter, and return a no-label vector with the value

I'm tending towards the first, as that'll leave us the option of doing the second in future.

I'm thinking this should be done the release after #1049 is released, to give users a chance to transition.

[brian-brazil]

0.16 will include bool, so we can drop scalar/scalar in 0.17.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.