Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #2566.
I had to do a bit of refactoring to make this work, because there is already a to_str instance for \forall T.@t, and hashmap has type @{...}, so I couldn't make a to_str instance for hashmap. Instead, I factored out the raw record type as "inner", and put the to_str instance on that. This required moving the private helper methods onto inner as well, which I guess works fine because of magical auto-dereferencing when calling them.
The thing I most worry about is that I have somehow changed the memory layout / behavior of hashmaps by doing this, but I don't think so.
There seems to be an aesthetic choice here between calling to_str on the keys and values, versus printing them with "%?". I chose the former as more consistent, but the latter produces slightly more useful output (printing strings quoted, e.g.) It seems like there should be a more unified notion of how to print things, somehow. Shouldn't "%?" be using the to_str iface, where present? Is there some iface it does use?
[Oh, and the actual printing code, which was the least trouble in this whole exercise, is stolen from the json module, which is why it uses a writer. I could do something else if it would be more idiomatic.]