Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite to support generic Display types inside of ANSIString #79

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mina86
Copy link

@mina86 mina86 commented Jan 5, 2023

Motivation here was to make ANSIString work with arbitrary Display
types such that values don’t need to be first converted into a String.
For example, in the past one would have to write something along the
lines of:

let (red, green, blue) = (255, 248, 231);
let red = Red.paint(format!("{red:02x}");
let green = Green.paint(format!("{green:02x}");
let blue = Blue.paint(format!("{blue:02x}");
let latte = format!("#{red}{green}{blue}");

This of course works but results in three String allocations. Those
can now be avoided since ANSIString can take any Display type and
postpone formatting to when the entire string is formatted:

let (red, green, blue) = (255, 248, 231);
let red = Red.paint(red);
let green = Green.paint(green);
let blue = Blue.paint(blue);
let latte = format!("#{red:02x}{green:02x}{blue:02x}");

Adding this feature lead to a rabbit hole of changing a lot of other
interfaces around ANSIString type.

Most notably, ANSIGenericString and ANSIByteString types no longer
exists. ANSIString is now the only type. Implementation of Display
trait and write_to method are now limited by the bounds on the generic
argument rather than on the type being ANSIString or ANSIByteString.

Similarly, there’s now just one ANSIStrings type which points at
a slice of strings.

Furthermore, util::substring now works on generic types and doesn’t
perform allocations on its own. E.g. when doing a substring over
Strings or Cows, the resulting substring borrows from the underlying
strings.

Lastly, how strings and bytes are written out has been completely
refactored. This is just an internal change though not observable by
the user.

@mina86 mina86 force-pushed the a branch 3 times, most recently from 227da5a to bfd02a6 Compare January 5, 2023 17:30
Motivation here was to make ANSIString work with arbitrary Display
types such that values don’t need to be first converted into a String.
For example, in the past one would have to write something along the
lines of:

    let (red, green, blue) = (255, 248, 231);
    let red = Red.paint(format!("{red:02x}");
    let green = Green.paint(format!("{green:02x}");
    let blue = Blue.paint(format!("{blue:02x}");
    let latte = format!("#{red}{green}{blue}");

This of course works but results in three String allocations.  Those
can now be avoided since ANSIString can take any Display type and
postpone formatting to when the entire string is formatted:

    let (red, green, blue) = (255, 248, 231);
    let red = Red.paint(red);
    let green = Green.paint(green);
    let blue = Blue.paint(blue);
    let latte = format!("#{red:02x}{green:02x}{blue:02x}");

Adding this feature lead to a rabbit hole of changing a lot of other
interfaces around ANSIString type.

Most notably, ANSIGenericString and ANSIByteString types no longer
exists.  ANSIString is now the only type.  Implementation of Display
trait and write_to method are now limited by the bounds on the generic
argument rather than on the type being ANSIString or ANSIByteString.

Similarly, there’s now just one ANSIStrings type which points at
a slice of strings.

Furthermore, util::substring now works on generic types and doesn’t
perform allocations on its own.  E.g. when doing a substring over
Strings or Cows, the resulting substring borrows from the underlying
strings.

Lastly, how strings and bytes are written out has been completely
refactored.  This is just an internal change though not observable by
the user.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant