Allow constructing LevelFilter via incrementation about log HOT 9 OPEN

You can use min((level_filter as usize) + 1, Trace::Trace as usize) as LevelFilter as LevelFilter has #[repr(usize)] to do this already.

I'm not sure this a common enough case that we need the crate, though.

from log.

Are you sure? All versions of Rust which I tried this on say that the cast from usize to LevelFilter is illegal¹. Given that the representation is known you can still hack the equivalent of C++'s reinterpret_cast, but...

from log.

This works: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1f583a914a1b153a80213f3cd78c8676 and it's safe only because of #[repr(usize)]. However you have to make sure the value is valid, i.e. not bigger than 5/LevelFilter::Trace, but the transmute itself is not UB.

from log.

Agreed, but it would still be nice not having to resort to unsafe, even if it is factually safe.

from log.

Agreed, but it would still be nice not having to resort to unsafe, even if it is factually safe.

Not really, the compiler can't ensure you do 6 as LevelFilter, which would be UB (5 is max valid value).

from log.

Agreed, but it would still be nice not having to resort to unsafe, even if it is factually safe.

Not really, the compiler can't ensure you do 6 as LevelFilter, which would be UB (5 is max valid value).

Yes, I know. I meant that with an API like TryFrom<usize> or the ones I suggested in my initial post would remove the need for library users to use unsafe code like the one you posted earlier.

from log.

Which brings us back to

I'm not sure this a common enough case that we need the crate, though.

from log.

I agree that some kind of increment/decrement on log levels and/or filters would be useful. It would also circumvent the stated reasons the other issues were rejected (#318, #460). Namely, it doesn't increase exposure of the underlying integer representation to users. It still does, however, expose the exact sequence of elements, e.g. adding a new level between two existing levels might break someone's code. I don't know if that is an issue.

from log.

It still does, however, expose the exact sequence of elements, e.g. adding a new level between two existing levels might break someone's code. I don't know if that is an issue.

The sequence is already exposed via the Iterator returned by LevelFilter::iter. A new feature for iterating over levels will thus at least not introduce this issue.

from log.