Add increment_severity() and decrement_severity() methods for Level and LevelFilter

[nebkor]

This is an alternative to exposing usize constructors for these enums, that still allows fluent manipulation of the level, a la,

// increase logging verbosity
std::log::set_max_level(std::log::max_level().up());

[tgross35]

Maybe these should be fn add(&self, n: u8) -> Self / subtract? To allow jumping multiple levels without repeated calls.

[nebkor]

That'd be fine with me, but I've gotten the impression that exposing any kind of numerically-oriented API is unwanted, aside from being able to cast as <integer>. I just hate having to do an unsafe transmute if I want to change the level.

[tgross35]

Fair point. For what it's worth, something like this would be much better than actually transmute:

fn log_level(a: u32) -> Level {
    match a {
        1 => Level::Error,
        2 => Level::Warn,
        3 => Level::Info,
        4 => Level::Debug,
        5 => Level::Trace,
        _ => panic!("unknown log level"),
    }
}

...but I get the reasoning to want something builtin.

[nebkor]

Funny enough, that's basically what I had in my own code before just going, fuck it, I'll transmute :)

But that's so much boilerplate for what should be something trivial!

[KodrAus]

Thanks for the PR @nebkor! Functionality wise this looks good to me. Naming wise, I think we should aim for something a bit more descriptive than up and down, since it's not obvious whether Info.up() should be Debug or Warn. What do you think of increment_severity() and decrement_severity(). Definitely more verbose than up or down, but they're easier to reason about.

[nebkor]

@KodrAus love the suggestion!

[KodrAus]

Thanks @nebkor!

This looks good to me.

[KodrAus]

The examples point this out already, but just leaving a note here for anyone who finds their way back to this PR; the semantics of increment and decrement here are the same as syslog's. To increment the severity means to reduce it. To decrement the severity means to increase it. I think this is still the correct behavior because it means we don't reverse the order of iteration, or comparison, when incrementing and decrementing.

[tisonkun]

the same as syslog's

@KodrAus could you provide a ref here? I don't find how syslog defines this rule.

Also, perhaps we can change the PR title to align with the final accepted method names.