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

Should we implement pub fn to_string on Writeable concrete types? #4590

Open
2 of 3 tasks
sffc opened this issue Feb 7, 2024 · 10 comments
Open
2 of 3 tasks

Should we implement pub fn to_string on Writeable concrete types? #4590

sffc opened this issue Feb 7, 2024 · 10 comments
Labels
C-meta Component: Relating to ICU4X as a whole S-small Size: One afternoon (small bug fix or enhancement)

Comments

@sffc
Copy link
Member

sffc commented Feb 7, 2024

Currently most Writeables implement Display which provides ToString. This means that people can write foo.to_string(), which uses the slower Display-based code path instead of the faster Writeable::write_to_string code path.

We could fix this in many cases by adding a pub fn to_string on concrete types implementing Writeable. This would cause foo.to_string() to use the faster path; the slow path would need a fully qualified call site such as ToString::to_string(&foo).

Note: pub fn to_string would return String, so write_to_string, which returns Cow<str>, would still be optimal. But at least pub fn to_string would be closer to optimal.

Thoughts?

@sffc sffc added C-meta Component: Relating to ICU4X as a whole needs-approval One or more stakeholders need to approve proposal labels Feb 7, 2024
@Manishearth
Copy link
Member

Seems fine. Should we just return a Cow there too?

@robertbastian
Copy link
Member

which uses the slower Display-based code path instead of the faster Writeable::write_to_string code path.

I'm gonna need numbers for this claim.

@sffc
Copy link
Member Author

sffc commented Mar 4, 2024

which uses the slower Display-based code path instead of the faster Writeable::write_to_string code path.

I'm gonna need numbers for this claim.

#4649

@robertbastian
Copy link
Member

Cool

sffc added a commit that referenced this issue Mar 5, 2024
See #4590

```
complex/write_to_string/medium
                        time:   [34.344 ns 34.380 ns 34.417 ns]

complex/display_to_string/medium
                        time:   [90.373 ns 90.482 ns 90.661 ns]
```
@sffc
Copy link
Member Author

sffc commented Mar 5, 2024

@Manishearth:

  1. Is it a breaking change to add a concrete impl of a to_string function on a type that already implements Display?
  2. Is it a breaking change to do that if the function returns Cow instead of String?

Seems fine. Should we just return a Cow there too?

Cow is slightly more annoying to deal with; I lean toward returning String directly. If people want the Cow they can call write_to_string as they can now. In most of our impls we return a Cow::Owned anyway.

@Manishearth
Copy link
Member

  1. Is it a breaking change to add a concrete impl of a to_string function on a type that already implements Display?
  2. Is it a breaking change to do that if the function returns Cow instead of String

Best avoided but this kind of thing mostly falls under not being breaking.

@Manishearth
Copy link
Member

If it returns Cow i'd perhaps name it something appropriately cowish

@sffc
Copy link
Member Author

sffc commented Mar 5, 2024

OK, consensus on the following proposal then?

  1. All ICU4X types that implement Writeable gain their own concrete pub fn to_string(&self) -> String function. The list of types can be found here.
  2. Mechanically, this can be done by adding a flag to impl_display_with_writeable! to add the desired function.
  3. To be extra safe, make this change in 2.0 (as opposed to 1.5 or 2.1)

LGTM?

@robertbastian
Copy link
Member

LGTM with the addition:
4. Properly document this prelude-trait-method shadowing and why we do it (maybe linking to the benchmark)

@Manishearth
Copy link
Member

LGTM with 4

@sffc sffc removed the needs-approval One or more stakeholders need to approve proposal label Mar 5, 2024
@sffc sffc added this to the ICU4X 2.0 milestone Mar 5, 2024
@sffc sffc added the S-small Size: One afternoon (small bug fix or enhancement) label Mar 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-meta Component: Relating to ICU4X as a whole S-small Size: One afternoon (small bug fix or enhancement)
Projects
Status: Small breakage (defer to end)
Development

No branches or pull requests

3 participants