Agreed, it would be pretty low effort, but yes, I figured it would be fine in contrib to not worry about it. Sounds like you're not really objecting either, so I'll leave it as is.

Good idea! (I should do that upgrade in my hobby project too.)

Heh, that's both clearer and more efficient. Silly me.

It adds an isize (offset) to a usize. I did that by converting the isize to usize and then doing a wrapping add. Happy to hear alternatives.

If the offset isize is positive, there is a chance of overflow. It's unlikely given what we're manipulating and the resulting if will be a bit uglier, but better safe than sorry.

The point of the wrapping_add() was to handle negative offsets. Do you mean that you'd prefer if we do something like this:

let offset = self.offsets[side];
if offset < 0 {
  self.base_range.start.checked_sub(-offset as usize)
} else {
  self.base_range.start.checked_add(offset as usize)  
}

I realized that clap will base the index on the declared order in the struct if you don't specify it, so I've stopped specifying them.

That looks good!

Yes, that's what I'm referring to (without the - sign in checked_sub, of course). The justification comes from the - maybe too paranoid - risk of overflow if both are positive.

The - should be there. Let's say the base range starts at 10 and the offset is -5, then you'll want to calculate 10 - 5 here. I could use checked_abs() if you're worried and it being usize::MIN.

The overflow should only happen if there are bugs. The offset comes from line 260.

By the way, I need to add .unwrap() calls too; checking_*() return Option<>.