Re: [Monotone-devel] resolving name conflicts; code style

[Zack Weinberg]

On Sat, May 10, 2008 at 4:06 AM, Stephen Leake
<address@hidden> wrote:
> "Zack Weinberg" <address@hidden> writes:
>> I would suggest passing just the relevant fields of app.opts.
>
> That makes sense. And now I see it is in HACKING; I guess I need to
> read that again :).
>
> There doesn't seem to be a way to pass an options set. There are four
> relevant fields; resolve_conflicts_given,  resolve_conflicts,
> resolve_conflicts_file_given, resolve_conflicts_file. That's unwieldy
> for a parameter list; it would be nice to be able to pass the set.

I suppose you could make up a struct for this.  There's no generic way to do it
and off the top of my head I can't think of anything that would be cleaner than
making up structs as necessary.

There's other places where it might be handy, I admit.

>> For the switch statement, I would recommend a default: clause
>> that's an invariant failure, like so:
>>
>>   switch (thing)
>>   {
>>     case one: ...; break;
>>     case two: ...; break;
>>     case three: ...; break;
>>     ...
>>     default:
>>       I(false);
>>    }
>
> Right, if the cases don't cover all the possible values.

Even if they do, sometimes the compiler doesn't understand that - like
in your case, you had a return "" after the switch just to shut it up
about control falling off the end of the function.

>> and don't put anything after the switch.
>
> This I don't understand; what's wrong with more processing after the
> switch?

In general that's fine, but when every case of the switch should
return (as in your original example) we don't want a dummy return.
The invariant failure should be enough to convince the compiler that
control never passes beyond the switch.

zw