-
Notifications
You must be signed in to change notification settings - Fork 211
Should we implement pub fn to_string
on Writeable concrete types?
#4590
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
Comments
Seems fine. Should we just return a Cow there too? |
I'm gonna need numbers for this claim. |
|
Cool |
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] ```
Cow is slightly more annoying to deal with; I lean toward returning |
Best avoided but this kind of thing mostly falls under not being breaking. |
If it returns |
OK, consensus on the following proposal then?
LGTM? |
LGTM with the addition: |
LGTM with 4 |
Currently most Writeables implement
Display
which providesToString
. This means that people can writefoo.to_string()
, which uses the slowerDisplay
-based code path instead of the fasterWriteable::write_to_string
code path.We could fix this in many cases by adding a
pub fn to_string
on concrete types implementingWriteable
. This would causefoo.to_string()
to use the faster path; the slow path would need a fully qualified call site such asToString::to_string(&foo)
.Note:
pub fn to_string
would returnString
, sowrite_to_string
, which returnsCow<str>
, would still be optimal. But at leastpub fn to_string
would be closer to optimal.Thoughts?
The text was updated successfully, but these errors were encountered: