filter callback in place of the "value" parameter

[jrlmx2]

Motivation

I'm primarily looking to utilize complex filtering through substring searching and a few other requirements.

I see issues referencing this everywhere but they have all been closed without resolution. From the previous issues, it looks like there is a potential compatibility issue offering support for Regexes in place of values for other platforms.

Can't you accept a closure in place of value? Its possible in JavaScript, Objective C, and Java
Essentially, you accept a closure that accepts the property value and returns a boolean. This solution is a catch-all of the niche cases that the current filter system doesn't support.

["func", "myProperty", (value) => /testRegex/.test(value)] // this is inefficient, don't use it in your code

Design Alternatives

Other methods include implementing each filter as as requested. My main case is string searching. String searching can be accomplished many different ways including some of the suggested
["regex", "property", /test/i]
["=~","property","substringToCompare"] // there are other versions of this suggested as well

Design

Which design should we implement?
The design I originally suggested accepting a callback in place of the value.

What are the advantages of this design?
The advantages are this is a catch all that will support ANYTHING people want to filter by.

What are some potential drawbacks of this design?
You cannot guarantee performance. The example I put above (["func", "myProperty", (value) => /testRegex/.test(value)]) is inefficient because it compiles a regex every time it runs. Imagine that on millions of features. Using this feature would definitely be "use at your own risk".
-->

Mock-Up

What will this design look like to developers?
To developers, this would simply be another tool. Closures are pretty standard in programming today. It may require a bit of a learning curve, but the extensive docs on the mapbox site should clear up any confusion.

What will this design look like to end users?
Largely enhanced filtering for more complex implementations. The filters can be infinitely complex allowing developers to create a better user experience.

Concepts

How will we teach this design?
What terminology will work best for the new concepts introduced by this design?
Call it user flexible filtering. Where users develop filters for their implementation. Definitely call the user defined filters closures when referencing code.

What existing precedents support the new concepts?
This is the exact use-case of closures and its implemented as such everywhere in javascript and other languages.

Where do the concepts set new precedents?
For mapbox this breaks out of the text only filter definition. It also makes mapbox run user-defined code which may break some internal issues.

Implementation

How you would implement the design in Javascript? (The below is simplified to get my point across.)

map.setFilter("myLayerID", ["func","myPropertyToCheck",(value)=>value.indexOf("est") === -1]

setFilter: function(layerID, filter){
const type = filter[0];
const property = filter[1];
const value = filter[2];
// loop through properties and find "property"
// existing switch case on type
case 'func':
 showPoint = value(propertyValue)
// existing code
}

How you would implement the design in C++?
Similar to the above, but using closures as documented below.
c++ closures

What parts of the Mapbox GL ecosystem will need to change to accommodate this design?
The filter processor.
Are there any important edge cases?
N/A

[mourner]

Substring search has been recently implemented and released in v1.6.0. See #8876 (in expression)

Can't you accept a closure in place of value?

No. The style specification has to conform to JSON format.