BitLogger/docs/api/level-enabled.md

name, group, category, update-time, description, key-word

name	group	category	update-time	description	key-word
level-enabled	api	level	20260512	Check whether a level passes a minimum threshold.	level enabled threshold public

Level-enabled

Check whether a Level passes a given minimum threshold. This is the core severity-gating helper used by synchronous and async logger is_enabled(...) checks.

Interface

pub fn Level::enabled(self : Level, min_level : Level) -> Bool {}

input

• self : Level - Candidate level being tested.
• min_level : Level - Minimum threshold the candidate must meet or exceed.

output

• Bool - true when self.priority() >= min_level.priority().

Explanation

Detailed rules explaining key parameters and behaviors

• The method compares levels by their numeric priority ordering.
• Matching the threshold exactly still counts as enabled.
• This helper is the level-level primitive behind logger threshold checks.
• It is useful when threshold logic should be expressed without requiring a logger instance.

How to Use

Here are some specific examples provided.

When Test A Level Against A Threshold

When code wants direct threshold logic:

let enabled = Level::Warn.enabled(Level::Info)

In this example, enabled is true because Warn is above Info.

When Reuse Logger-style Gating In Helpers

When a utility should mirror logger severity checks:

if level.enabled(Level::Debug) {
  logger.info("level is active")
}

In this example, the same ordering rule used by logger APIs is applied directly.

Error Case

e.g.:

• There is no failure path for valid level values.

• If callers need to know whether a record survives filters or sinks, enabled() alone is not sufficient because it only covers severity gating.

Notes

1. Use this helper when threshold logic should stay independent of any logger instance.

2. Prefer Logger::is_enabled(...) when you already have a logger and want to respect its configured minimum level directly.