Convert between predicate options and collator expressions

[1ec5]

The [c] and [d] options are now supported within comparison predicates for case and diacritic insensitivity, respectively. Along the way, the mbgl code that detects expressions in filters had to be updated to allow a collator as the third argument to a comparison expression.

Fixes #12269. Working towards #11786.

/cc @ChrisLoer @fabian-guerra @anandthakker

[1ec5]

Apparently this code was ported from GL JS code that will also need to be updated.

[ChrisLoer]

Filed as mapbox/mapbox-gl-js#6920

[anandthakker]

Maybe slightly better would be:

length != 3 || (isArray(arrayMember(filter, 1)) || isArray(arrayMember(filter, 2)))

[ChrisLoer]

The reasoning being that the default should be "this is an expression", and we should scope the fallback to legacy filters as tightly as possible?

[1ec5]

Makes sense. Done.

[anandthakker]

The reasoning being that the default should be "this is an expression", and we should scope the fallback to legacy filters as tightly as possible?

Yeah, pretty much: sending as many inputs as possible through the expression parsing pipeline, since that will be more and more likely what users will be trying to write, and so expression-related validation messages are more likely to be useful

[ChrisLoer]

Does this means 'Québec' =[] 'Quebec' will use a collator (and thus the current locale) vs. 'Québec' = 'Quebec' doing non-locale-aware comparison?

[1ec5]

As long as an option is specified in brackets, it’ll use a collator. To match Core Data behavior, I suppose we could default the locale to en-posix when c or d is specified unless l is also specified.

A literal =[] is invalid syntax; there has to be an option. NSPredicate will raise an exception immediately on initialization.

[ChrisLoer]

I think the current behavior sounds right. 👍

[ChrisLoer]

🤔 Now that I see this, I wonder if it makes sense to treat the core feature ("support styles using the collator expression") as a separate changelog entry from the platform-specific wrapper...

[1ec5]

That’s a good point; we normally mention the JSON equivalent when that’s also new.

[1ec5]

Updated the changelog entry.

[ChrisLoer]

To make sure I'm understanding: if you wanted to explicitly do locale-sensitive comparison with something other than the current locale, you'd have to manually craft your expression, because NSPredicate only supports a binary "locale-sensitive"?

[1ec5]

That’s correct. The syntax would look something like this:

NSPredicate(format: "MGL_FUNCTION('==', 'QUEBEC', 'Québec', MGL_FUNCTION('collator', %@))", ["case-sensitive": false, "locale": "fr-CA"])

There’s a couple things we could adjust at the SDK level, like allowing locale to be set to an NSLocale instead of a raw locale identifier. But my understanding is that we normally want developers to keep using the default collator for better performance, so maybe it doesn’t help much to simplify the locale-specific collator syntax.

[1ec5]

I made some last-minute changes so that this predicate would work:

• The collator options object is no longer wrapped in a literal expression when converting from NSExpression to JSON.
• The MGL_FUNCTION() syntax is used instead of the ==[…] syntax when a locale is specified.

[fabian-guerra]

👍🏼

[fabian-guerra]

Nice!