Automatically type-annotate arguments to "==", "!=" expressions

[peterbodo]

Motivation

After 2 hours of experimentation, I relaised that a simple tag filter looks like this:
["all",["has","amenity"], ["==", ["string",["get", "amenity"]], "toilets"]]

because I have to ensure first that amenity exists, than making its value string, in order to avoid type errors.
This should not be so difficult, and definitely people will not love expresssions, if this very common use case is so difficult to achieve.

Design Alternatives

["==","amenity","toilets"]
I think, this should work out of the box. Because properties is a special object, so I suggest a direct access, and various type issues should not be handled in the forntend code.

(Why on Earth, "get","something" is a Value, when it is in fact a "String"??? :) )

I could get along with:
["==",["get","amenity"],"toilets"]

Design

no idea

Mock-Up

no idea

Concepts

no idea

Implementation

no idea

[anandthakker]

Type inference is performed automatically in most cases, but currently, == and != are an exception. I agree that requiring explicit type annotations for == / != is not ideal. (See also: #5761 (comment))

As an immediate option to simplify your expression a bit, you could use, ["==", ["to-string",["get", "amenity"]], "toilets"]. What this does is uses to-string to convert amenity to a string (no matter what its type happens to be in the actual data). Since to-string can accept null values, this approach means you don't have to do the [has,...] check first.

Why on Earth, "get","something" is a Value, when it is in fact a "String"?

get must be typed value, because at "compile" time (i.e., when we parse the expression), we cannot know ahead of time what the feature data will actually look like.

[peterbodo]

@anandthakker Thanks, That looks much better.
Maybe I should dig more into expressions.
Is there a more detailed documentation/examples for common use cases somewhere? I could not find any.