Complex boolean expressions

[Revolucent]

Importing CDQI >= 4.0 into a compilation unit has an unfortunate and very annoying side effect. When complex boolean expressions are used with types supported by CDQI, the compiler thinks these are trying to create NSPredicates rather than Bools. For example:

// This code works just fine:
let x = 3
if x > 0 { 
    /* blah blah */ 
}

// This code does not:
if (x > 0) || (x < -44) {
   /* blah blah */
}

The compiler thinks we are trying to create an instance of NSPredicate in the second if statement. This is a pretty serious bug, although interestingly I have several large codebases that use CDQI and only encountered this in one place.

The solution is to require that the LHS of a CDQI expression that generates an NSPredicate be an instance of an Attribute subclass.

[Revolucent]

We will also need a unit test to make sure this doesn't happen in the future.

[Revolucent]

This is not really a major change as far as compatibility goes, so it will be a simple point release.

[patgoley]

I thought about this and meant to bring it up to you. Yeah, seems like a good fix requiring lhs to be an attribute. Don't really see the use in building a fetch request where both right and left expressions are constants.

[Revolucent]

Well, it was always in the back of my mind, but when I saw ordinary boolean expressions work, I (wrongly) assumed more complex ones would as well, thanks to type inference. Since an if expression must take a boolean, one would think type inference would take care of it, but it doesn't seem to. (Is this a compiler bug? Not sure.)

[Revolucent]

@patgoley I'm in the midst of taking care of this right now, FYI.

[Revolucent]

It turns out that allowing only Attribute on the LHS is too restrictive. Instead, there's an empty protocol called PredicateComparable. The LHS must implement this protocol in order to participate in comparisons. It is implemented by Attribute and Count, and is available for future types if we need it. This makes things more flexible.