Consider reviewing type-check consistency of function arguments

[springcomp]

Some functions are defined as taking arguments of a specific type, but are still allowed to return null when given invalid types.

For instance the ceil() function returns null on invalid input in the original implementations.
This seems to contradict the blanket statement from the specification that:

“Function arguments have types. If an argument for a function has the wrong type, an invalid-type error will occur.”

JMESPath Community implementations enforce strict type checking as much as possible, unless a compliance test exists.
Please, consider reviewing type-checking and make it more consistent.

Maybe this should be documented in the compatibility section of the compliance test suite?

[hell-racer]

From my perspective (and from what I think 'convenience' point of view) it would be nice if all functions returned null if argument is null and throw exception if the argument is of wrong type. Usually if an argument has incorrect type means that you have an error in your expression, and if an argument is null - usually means that your expression is correct but the data lacks something (which is usually ok). Functions throwing if argument is null means that all the expressions are cluttered with 'fallback' values, e.g. instead of length(a) you have length(a || '') (or a && length(a)) all over the place. It is extremely visible when you have large templates that consist only of JmesPath expressions.
Now, there are some edge cases... E.g. it would be nice if join() just skipped null values and automatically converted numbers to strings (and throw if there are some objects or arrays among items).