Expression transformations

[1ec5]

In the iOS and macOS SDKs, automatic label localization (MGLStyle.localizesLabels) replaces references to one name_* field with another in every symbol layer. This is a trivial operation for constant expressions and was a manageable operation for legacy style functions, but expressions are far too complex to transform in an ad-hoc manner. For now, #10726 will avoid localizing non-constant expressions, and #10713 would reenable the feature for data and/or camera expressions.

Essentially what’s needed is a way to visit every subexpression and transform it according to a block. It might piggyback on eachChild() to some extent, but it would recurse through the entire subexpression tree, and the callback would return a replacement object. This transformation function could be implemented purely at the Objective-C level, but a pure C++ implementation would be much more robust, avoiding any risk from lossy roundtripping between C++ and Objective-C types.

/cc @anandthakker @tobrun

[1ec5]

It would be ideal if mbgl could expose a dedicated way to transform an expression, but after #11156 lands, this feature could also be implemented at the SDK level, albeit with an impact on performance:

1. Serialize the expression as an mbgl::Value.
2. Convert the mbgl::Value to an NSArray.
3. Use NSKeyedArchiver or NSJSONSerialization to archive the NSArray.
4. Use NSKeyedUnarchiver or NSJSONSerialization to unarchive an NSMutableArray with mutable descendants.
5. Manually recurse down the NSMutableArray, calling the callback on each object encountered.

[anandthakker]

@1ec5 I'm thinking that a round-tripping approach like #10944 (comment) might actually be preferable to adding a general-purpose transformation API. The former would have the advantage of going through the expression parsing (and thus type checking) code path, and the latter seems like adding a lot to the expression API surface for a single, specific use case.

[1ec5]

A general framework for expression transformations is no longer needed in mbgl for #10713. In fact, we have a pretty good start to such a framework in the NSExpression category, because NSExpression’s AST made it quite easy to do so. Round-tripping is no longer much of a concern after the changes in #11472.