Remove ["properties"] expression

[anandthakker]

The existence of the ["properties"] expression means that the Feature interface we use must provide access to a full map of a feature's properties, rather than just a getPropertyValue(key). This could be a deceptively costly operation. Removing this expression would let us to narrow the feature interface and avoid an unnecessary trap for expression authors. Are there any use cases that can only be served by a ["properties"] expression (instead of just ["get", key] and ["has", key])?

[anandthakker]

cc @lucaswoj @GretaCB

[lucaswoj]

I asked @peterqliu @ryanbaumann @kalimar and @Kilatsat if they'd ever used ["properties"]. None of them had encountered a use case yet.

[1ec5]

Since a list of feature properties isn’t declared at the source level (mapbox/tilejson-spec#14), it may be useful to find property names matching a particular pattern. Localization may call for this kind of flexibility at some point in the future, since it’s customary for localized names to be defined on keys named with a finite but large set of ISO language codes. (See #6197 for an idea of how complicated things could get.)

I agree that properties as written could be a performance trap for developers. A couple ideas for alternatives:

• Somehow make the properties operator lazy so that the map is only fully computed when calling has or get on the result of properties.
• Replace the properties operator with a property-names operator that returns an array of property names defined on a feature.

[jfirebaugh]

Style authors are amazingly innovative and I'm sure they'll find a use for ["properties"] where nothing else would do. I'm more inclined to discourage misuse by providing a linting tool which could detect things like ["get", "foo", ["properties"]], suggest the replacement, and explain why it's an improvement.

#6252 suggests another kind of static analysis that's more sophisticated than what we may be able to offer at runtime, and is also something that a linter could provide.