Exporting Result at the crate root can cause conflicts with std::result::Result

[rtyler]

Filing this just because I had to go clean up a lot of code in my own project after not noticing that the Result other areas of my code were relying upon was actually dipstick::Result rather than the std Result.

The following line in lib.rs can cause issues for users (like me) who are basically copying and pasting from the examples which have use dipstick::*;

src/lib.rs

pub use crate::error::Result;

This basically causes my functions with Result to now be expecting dipstick::Result rather than the built in.

My suggestion would be to just remove pub in that declaration or otherwise stop exporting it. If users need to access the Result type, they can just as easily reference or bring in dipstick::error::Result

[fralalonde]

You are right and I can understand how frustrating that problem must have been to solve. What you propose makes sense but I will take just a bit more time (a few hours?) to evaluate the options and see how other crates do it.

[fralalonde]

After reviewing it's usage, I've come to the conclusion that a customResult brings no value, so I've removed it entirely. flush() now returns an std::io::Result... and that's it. As this breaks the API I've bumped the crate version again. I've made a self PR that you might care to review before I merge it and release it sometime this weekend: #81

I've also yanked the just released v0.8.0 to minimize API churn for some hypothetical newcomer.