Skip to content
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

Default {} is confusing, while {:#} is much better #111

Open
ndmitchell opened this issue Sep 4, 2020 · 3 comments
Open

Default {} is confusing, while {:#} is much better #111

ndmitchell opened this issue Sep 4, 2020 · 3 comments

Comments

@ndmitchell
Copy link

We've been using anyhow extensively, and it's worked out great. There's just one super confusing thing. I would expect:

println!("{}", anyhow!("My error message").context("on a file"))

To print at least My error message, and ideally on a file. But it just prints on a file. I know {:#} is available, but I've yet to find a case where we didn't want {:#} and the usage of {} is pretty pervasive - we've had it when printing messages nested, as format strings to thiserror etc. It is the bug we seem to make every single time. I appreciate compatibility constraints might be hard, but switching the two (or even making them both the same) would be easier to use.

@link2xt
Copy link

link2xt commented Sep 30, 2020

Related issue: dtolnay/thiserror#98

But I like this proposal to fix anyhow instead.

@Hocuri
Copy link

Hocuri commented Mar 3, 2021

What about a feature flag that makes {} behave the same as {:#}? Would this be possible?

@link2xt
Copy link

link2xt commented Mar 3, 2021

Features are enabled when at least one dependency enables it, so they should not be used for "options". Otherwise pulling in a dependency which uses this "feature" will enable it for you and break your code and code of other dependencies which do not expect it.

Repository owner locked and limited conversation to collaborators Feb 21, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants