Yes, your version makes sense. Mine really did not.

Merged.

Moritz, there were some logic bugs in the m&s parameter code (if both options
were set, the max_states option was used for both values instead of using both
inputs; if exactly one of the options was used, one value was left at the
uninitialized -1 and the other was set based on that), so I rewrote it again. 

Can you verify that the version that I pushed to the default branch in the
master repository makes sense? I did test most combinations that I could think
of, but a second pair of eyes won't hurt.

It's okay if you merge now, I'll just merge it into my issue232-branch.

We probably discussed this, but I forgot. Is it OK if I merge this now, so that
we can use this functionality in the PDB code, or should I consider this blocked
until issue232 has landed?

reminder: I can update the patch for this when the automatic code
generation (issue 232) is done - will make it simpler to merge.

Looks fine.

Looks fine to me. Gabi, any objections?

One possible way: http://codereview.appspot.com/4442076/diff/1/src/search/raz_mas_heuristic.cc?context=10&column_width=80

I had to wrap the boolean "mandatory"-parameter in OptionFlags to avoid ambiguity (because add_option is overloaded).

Any improvement suggestions or alternatives? Otherwise I'll finish&test this when I'm back home (tuesday/wednesday). The documentation output also needs to be changed a bit.

So, "optional, no-default" parameters in addition to "mandatory" and "optional with default".
Probably not hard, but I have to think about it a bit. Will try to implement this on the weekend.

There are some cases where we have an optional argument to a heuristic (or other
structure) and there is no reasonable default value that fits the type of the
option, since the "default behaviour" is special in some way.

For example, in the PDB code that is currently being developed, there is an
optional "pattern" argument which is a list of ints, and we would like to be
able to find out whether or not a pattern was specified. (Using e.g. an empty
list as a default would not be possible, since that's a valid pattern
specification.) So it'd be good to be able to explicitly query if the value of
an option is "missing" or "unspecified". This could also be used in other cases
where we currently use invalid placeholder values like -1 (e.g. for the m&s
heuristics) as the default.

Moritz, would it be much work to add this?