ogham / rust-number-prefix

Library for numeric prefixes, such as “Kilo” or “Giga” or “Kibi”.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Limited built-in formatting: intended or not?

masklinn opened this issue · comments

This should probably be a discussion topic but they're not enabled so I figure an issue is the least-bad way to ask before (possibly) working on implementing it: I've been looking at number_prefix as a way to do display formatting (intended for end-users), however I was wondering about a few limitations / absent features and whether their lack was intended, or they just weren't thing you'd ever needed:

  • I understand that the Standalone/Prefix split is useful for cases where the user wants to handle the standalone case separately, but they're annoying for the opposite. Could it be an option to not have to deal with it? I'm imagining accessors or formatting helpers on NumberPrefix directly e.g. NumberPrefix::prefix which would return an Option<&str> (or an empty string for Standalone), possibly formatting helpers so it's not necessary to case-match the entire thing by hand. It's quite odd that there's support for parsing a NumberPrefix but not for formatting one.
  • At the moment, number_prefix basically runs the adjustment until it's entirely within a prefix (so ends up with a modulo 1000 or 1024), would it be possible to manually limit or update this adjustment, aka "denormalise" NumberPrefix by hand either to set it to a specific prefix or to move it around (e.g. next/prev)? E.g. use number_prefix to always display amounts in gigs but mostly use it for the API, or for uniform handling of SI/decimal versus binary prefixes (aka generalised ISQ).

Also not really part of my wants, but asking while at it: is i18n a consideration or not really? Though I figure such an eventuality would probably take the form of explicit overloads with some sort of formatting / locale parameter anyway so it's not really a concern for the current design scope.