[ios, macos] Change the format for case expressions to a flat structure.

[fabian-guerra]

Fixes #11007

• Add compact syntax.
• Add multiple branch support.
• Add tests.
• Add iOS 8.x support.

[1ec5]

A simple conditional would look like this:

// If conditional, then trueExpression, else falseExpression
TERNARY(conditional, trueExpression, falseExpression)

A nested conditional would look like this:

// If firstConditional, then firstExpression,
//   else if secondConditional, then secondExpression,
//     else falseExpression
TERNARY(firstConditional, firstExpression,
        TERNARY(secondConditional, secondExpression,
                falseExpression))

So it’s the falseExpression that we need to examine here, not the trueExpression.

[1ec5]

For #11007, we need to implement a new custom NSExpression function that can represent multiple branches. TERNARY() only supports “if…then”, and “else”, but we need “else if…then” as well.

If NSExpession were to support this feature natively, I would expect it to have initializers similar to +[NSDictionary dictionaryWithObjects:forKeys:] and +[NSDictionary dictionaryWithObjectsAndKeys:], in other words:

• +[NSExpression expressionForTrueExpressions:forConditionals:falseExpression:]
• +[NSExpression expressionForTrueExpressionsAndConditionals:falseExpression:]

We could implement these methods in this PR to help address #11016 and remove the single-conditional initializer in #11278 (comment).

Once #11015 is implemented, I think the underlying implementation could become clearer, something like MGL_TERNARY(firstConditional, firstExpression, secondConditional, secondExpression, …, falseExpression). In the meantime, the existing FUNCTION() syntax should suffice.

[1ec5]

-[NSArray count] returns an NSUInteger, so to avoid the risk of overflow, index should be an NSUInteger.

[1ec5]

This implementation essentially has the developer writing something like this:

[NSExpression expressionWithFormat:@"FUNCTION({firstConditional, firstExpression, secondConditional, secondExpression, …, falseExpression}, 'mgl_case')"]

It’s good that the arguments all sit side by side now instead of requiring nested TERNARY() expressions. However, placing all the arguments inside a single aggregate expression would be inappropriate, because case behaves like a control structure rather than a typical mathematical function.

Per #11450 (comment), I think this function should be used more like this:

[NSExpression expressionWithFormat:@"FUNCTION(firstConditional, 'mgl_case:', firstValue, secondConditional, secondValue, …, falseValue)"]

It looks weird, but we need an operand, and it’s natural for the first conditional to be that operand. This design would require a category method of NSPredicate with the following vararg signature:

- (id)mgl_case:(id)firstValue, ...;

As part of #11472, we can implement a control structure–like MGL_SWITCH: function that’ll have a call site like this:

[NSExpression expressionWithFormat:@"MGL_SWITCH(firstConditional, firstValue, secondConditional, secondValue, ..., falseValue)"]