Is your feature request related to a problem? Please describe.
Many style properties accept arrays, but today these arrays must be static when authored in expressions. While literal can construct arrays and objects, it intentionally does not evaluate expressions within them. This makes some data-driven styling use cases impossible or requires verbose workarounds.
As the style specification adding support for semiliteral in MapLibre Native would be nice for feature parity.
Describe the solution you'd like
Implement support for the semiliteral expression operator in MapLibre Native.
semiliteral should evaluate expressions within arrays and objects while preserving the existing behavior of literal, enabling dynamically computed array- and object-valued expressions in a backwards-compatible way.
Describe alternatives you've considered
Workarounds such as selecting between precomputed arrays or encoding values in other forms are often verbose, limited, or cannot express all desired styling behavior.
Changing the semantics of literal is not a viable alternative because it would break existing styles.
Additional context
This is intended to bring MapLibre Native in line with maplibre/maplibre-style-spec#950.
Is your feature request related to a problem? Please describe.
Many style properties accept arrays, but today these arrays must be static when authored in expressions. While
literalcan construct arrays and objects, it intentionally does not evaluate expressions within them. This makes some data-driven styling use cases impossible or requires verbose workarounds.As the style specification adding support for
semiliteralin MapLibre Native would be nice for feature parity.Describe the solution you'd like
Implement support for the
semiliteralexpression operator in MapLibre Native.semiliteralshould evaluate expressions within arrays and objects while preserving the existing behavior ofliteral, enabling dynamically computed array- and object-valued expressions in a backwards-compatible way.Describe alternatives you've considered
Workarounds such as selecting between precomputed arrays or encoding values in other forms are often verbose, limited, or cannot express all desired styling behavior.
Changing the semantics of
literalis not a viable alternative because it would break existing styles.Additional context
This is intended to bring MapLibre Native in line with maplibre/maplibre-style-spec#950.