Question

How can I check multiple expressions in one Matcher fragment?

For example:

class Foo extends Specification {
   "Retrieving open issues" should {
      "return expected properties with expected data" in     {
         val issue = Bar.openIssues.head

         issue must not beNull
         issue.number must beEqualTo(1) 
         issue.state must beEqualTo("open")
         issue.title must beEqualTo("first issue")
      }
   }
}

Gives error

[error]  type mismatch;
[error]  found   : Int
[error]  required: org.specs2.matcher.Matcher[Issue]
[error]                         issue.number must beEqualTo(1)

Eric references a “classical” type inference issue in this comment, but couldn’t find an answer.

Answer 1

The problem lies in this line:

issue must not beNull

Because it is written in operator notation the compiler must infer dots and parentheses at the right position. Following the rule that obj meth arg is the same as obj.meth(arg) this line is interpreted as:

issue.must(not).beNull<missing_arg>

beNull is a member called on the returned value of issue.must(not). The compiler follows the rules of operator notation and treats it as meth while issue.must(not) is treated as obj. Because operator notation always requires that a call must have the form obj meth arg, in the above example the compiler is hold to throw an error because of invalid syntax. But it doesn’t do it since there are two further rules:

1. The white space that separates the identifiers in operator notation must not only contain spaces or tabs, it can also contain a single(!) new line sign.
2. If no arg can be found an empty argument list is inserted implicitly.

Because of (1), the compiler treats the next line as arg:

issue.must(not).beNull(
issue.number).must(beEqualTo(1))

This is not how the code should be interpreted. To solve the problem it is possible to enclose the whole expression in parentheses:

(issue must not beNull)

or to separate the lines by an empty line:

issue must not beNull

issue.number must beEqualTo(1)

Both solutions work because of (2) the compiler can insert an empty argument list.

Note: If (2) must be applied this is also called a postfix operator. In 2.10 they treat a warning because – as one can see with this question – they can lead to tricky behavior.