Add key and value methods to DebugMap #2696
Conversation
KodrAus
added
A-fmt
text/0000-debug-map-key-value.md
Outdated
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| The proposed `key` and `value` methods are't immediately useful for `Debug` implementors that are able to call `entry` instead. This creates a decision point where there wasn't one before. The proposed implementation is also going to be less efficient than the one that exists now because it introduces a few conditionals. |
There was a problem hiding this comment.
Regarding efficiency, I would suggest testing this out with a PR and then doing a timer build to see how much perf regresses (that just affects compile times but it's better than nothing). With that data we can evaluate the drawback better.
There was a problem hiding this comment.
I opened up a PR (rust-lang/rust#60458) that we can use to check correctness and get some timings 👍
I don't expect the difference to be significant, since it amounts to a few conditionals but it'll be good to verify!
There was a problem hiding this comment.
Alrighty, I posted a quick benchmark in the PR, but also inlining the results here:
Before (current .entry()) |
After (.key().value()) |
|---|---|
| 36 ns/iter (+/- 7) | 44 ns/iter (+/- 2) |
text/0000-debug-map-key-value.md
Outdated
|
|
||
| - Write an alternative implementation of the format builders. The output from this alternative implementation would need to be kept reasonably in-sync with the one in the standard library. It doesn't change very frequently, but does from time to time. It would also have to take the same care as the standard library implementation to retain formatting flags when working with entries. | ||
| - Buffer keys and format them together with values when the whole entry is available. Unless the key is guaranteed to live until the value is supplied (meaning it probably needs to be `'static`) then the key will need to be formatted into a string first. This means allocating (though the cost could be amortized over the whole map) and potentially losing formatting flags when buffering. | ||
|
|
There was a problem hiding this comment.
A third option here is to simply not error when keys and values come alone. That might actually be useful in some weird semi-map semi-array cases. That would also be more efficient?
There was a problem hiding this comment.
Hmm, that's an interesting thought 🤔 I think that might just mask incorrect implementations though. I imagine we'd be tracking the same additional state too so that we knew when a key or value called 'out of order' should be formatted in a set-like way rather than a map-like way.
There was a problem hiding this comment.
Yeah quite possibly.
Would be good to record this in the text of the RFC in any case. :)
text/0000-debug-map-key-value.md
Outdated
| pub fn finish(&mut self) -> fmt::Result { | ||
| // Make sure there isn't a partial entry | ||
| if self.has_key { | ||
| return Err(fmt::Error); |
There was a problem hiding this comment.
Creating a fmt::Error like this isn't allowed. From https://doc.rust-lang.org/nightly/std/fmt/index.html#formatting-traits:
a formatting implementation must and may only return an error if the passed-in Formatter returns an error.
As this indicates a programming error I think an explicit panic here would be correct.
There was a problem hiding this comment.
Sure! A panic seems reasonable.
|
CC @japaric in case you're interested, given your work on an alternative formatting stack. |
|
Nominating for discussion at the next triage to get some more input from the wider libs team. |
|
I'll go ahead an propose to merge, seems like a reasonable feature to me! @rfcbot fcp merge |
|
Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
rfcbot
added
the
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
removed
the
proposed-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
rfcbot
added
finished-final-comment-period
…hton Add key and value methods to DebugMap Implementation PR for an active (not approved) RFC: rust-lang/rfcs#2696. Add two new methods to `std::fmt::DebugMap` for writing the key and value part of a map entry separately: ```rust impl<'a, 'b: 'a> DebugMap<'a, 'b> { pub fn key(&mut self, key: &dyn Debug) -> &mut Self; pub fn value(&mut self, value: &dyn Debug) -> &mut Self; } ``` I want to do this so that I can write a `serde::Serializer` that forwards to our format builders, so that any `T: Serialize` can also be treated like a `T: Debug`.
…ue, r=alexcrichton Stabilize the debug_map_key_value feature RFC: rust-lang/rfcs#2696 Tracking issue: rust-lang#62482 Stabilizes the `debug_map_key_value` feature, which covers: ```rust impl<'a, 'b> DebugMap<'a, 'b> { pub fn key(&mut self, key: &dyn fmt::Debug) -> &mut DebugMap<'a, 'b> {} pub fn value(&mut self, value: &dyn fmt::Debug) -> &mut DebugMap<'a, 'b> {} } ``` These methods are small and self-contained, and are used as the basis for the existing `DebugMap::entry` method, so have been used in the wild for the last 6 months or so.
Rendered
Add two new methods to
std::fmt::DebugMapfor writing the key and value part of a map entry separately: