More formatting options at no cost

[tisonkun]

The humansize crate allows users to customize the formatting options in multiple ways.

So far, bsize supports only customization between DisplayFormat:Binary and DisplayFormat:Decimal. It'd be better to investigate humansize's option to see which ones are suitable for this crate and thus we may have a Display::options(DisplayOptions) method for it.

Ref - https://docs.rs/humansize/latest/humansize/struct.FormatSizeOptions.html

[Colerar]

I don't understand what “no cost” in the title specifically refers to. Does it mean no runtime cost, no maintainer cost, or no user cost?

I think it depends on your idea of ​​the specific use case for this crate. and... taste?

In my word, the humansize crates seems too unopinionated. For example, the crate even provides a nonsensical WINDOWS option for outputting strings with IEC values but SI units.

Here are some of my comments on each option in FormatSizeOptions, :) for your reference:

• base_unit: BaseUnit

  Whether the value being formatted represents an amount of bits or bytes.

  ❓ I'm not sure if it's worth supporting bits as well?

• kilo: Kilo

  The scale (binary/decimal) to divide against.

  ❌

• units: Kilo

  The unit set to display.

  ❌ I don't think these kilo and units option should be separate ones. The divisor and the displayed unit system should match. Mixing them creates misleading output.

• decimal_places: usize

  The amount of decimal places to display if the decimal part is non-zero.

  ❌

• decimal_zeroes: usize

  The amount of zeroes to display if the decimal part is zero.

  ❌ The behavior of these two options feels weird to me:

  use humansize::{format_size, FormatSizeOptions, DECIMAL};
  
  fn main() {
    let decimal_places = FormatSizeOptions::from(DECIMAL).decimal_places(5);
    let decimal_zeros = FormatSizeOptions::from(DECIMAL)
      .decimal_places(5)
      .decimal_zeroes(5);
    println!("{}", format_size(3048usize, decimal_places)); // 3.04800 kB
    println!("{}", format_size(3048usize, decimal_zeros)); // 3.04800 kB
    println!("{}", format_size(0usize, decimal_places)); // 0 B
    println!("{}", format_size(0usize, decimal_zeros)); // 0.00000 B
  }

  If the caller asks for 5 decimal places, I would expect the formatter to consistently display 5 decimal places, whether the fractional part is zero or non-zero.

  So .decimal_places(5) should behave like the current .decimal_places(5).decimal_zeroes(5). Splitting this into two options makes the behavior harder to understand without adding much practical value.

• fixed_at: Option<FixedAt>

  Whether to force a certain representation and if so, which one.

  ✅ LGTM.

• long_units: bool

  Whether to use the full unit (e.g. Kilobyte) or its abbreviation (kB).

  ❌ I don't think this belongs in the core formatter. kB, KiB, MB, etc. are unit symbols, not merely abbreviations. Symbols are relatively language-neutral, while names like kilobyte or kibibyte are English display strings.

  Supporting long unit names seems to cross into localization / presentation-layer territory. Once the crate supports kibibyte, it has to answer questions about pluralization, capitalization, locale-specific names, and probably parsing symmetry as well. If the formatter can emit kibibytes, users may expect the parser to accept kibibyte, kibibytes, Kilobyte, localized names, and so on.

  That feels like unnecessary complexity for this crate. I would rather keep the formatter focused on standardized symbols and let callers handle long or localized unit names themselves.

  As a concrete example, I have observed that Apple Spotlight on a zh-Hans system handles oz, ounces, and 盎司 rather inconsistently.

• space_after_value: bool

  Whether to place a space between value and units.

  ❌ I want this option to be unavailable so that there will always be a space after the value. I have no idea when this option should be disabled.

• suffix: &'static str

  An optional suffix which will be appended after the unit. Useful to represent speeds (e.g. `1 kB/s)

  ❌ Seems redundant because caller can simply concat a suffix.

So here is a summarized list of what I would personally like to support:

• base_unit: BaseUnit
  • Maybe.
• unit_system: UnitSystem
  • SI or IEC
• decimal_places: usize
• fixed_at: Option<FixedAt>

[tisonkun]

@Colerar Thanks for your input! Let me see if it's enough for us to deliver some options now.

For "no cost", I mainly focus on cognitive burden - i.e., whether supporting such an option would make the overall APIs harder to understand. Your feedback is very valuable in answering this question!