xml-rs
xml-rs copied to clipboard
Allow EventWriter to use fmt::Write in addition to/instead of io::Write
In trying to write a general Element type, i realized that if i wrote a fmt::Display implementation for it, certain methods of serialization would be much easier. However, i hit a wrinkle with EventWriter: it's focused around using a type that implements io::Write. A quick look behind the curtain makes it seem like it might work out, but trying to unify these traits also sounds like a recipe for coherence disaster. I'll try tinkering on it, but if you've thought about this before, i'd like to know if other concerns had come up.
No, I didn't think of this before, mainly because fmt::Writer is not intended as a general I/O utility, it is just a support trait for the formatting infrastructure. Frankly, I'm not sure how to unify these types in the writer except for creating adapters.
I'm not sure I want to support this directly, specifically because the main I/O traits are std::io ones, but I do understand your use case. Let me think on it some more :)
Update: In a local fork, I just tried using a wrapper trait that was impl'd for T where T: io::Write and also just for fmt::Formatter, but that was still shot down by coherence. I chatted a little with some people on IRC about it, and it turns out that attempting to move this upstream somehow would likely involve a breaking change to libstd. -_- If specialization were stable, this would be easier, but until then (or until the epoch RFC settles down and we actually hit the next revision), this may not be doable.
If you want to implement io::Write for the Formatter, you have to implement it for a NewType NewType(fmt::Formatter). Unfortunately the trait doesn't guarantee UTF-8 well-formedness, so this would have to have redundant checks for it to be sound.
I think support for fmt::Write is a nice-to-have, but not a necessity, so I'm not planning it.