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

How do I print a bool? #170

Closed
gnzlbg opened this issue Jun 6, 2015 · 7 comments
Closed

How do I print a bool? #170

gnzlbg opened this issue Jun 6, 2015 · 7 comments

Comments

@gnzlbg
Copy link

gnzlbg commented Jun 6, 2015

I would like to print a C++ bool, such that when it is true it outputs "true", and false outputs "false". I can workaround this with the ternary operator, but it shouldn't be necessary.

There doesn't seem to be anything about this in the syntax docs.

@vitaut
Copy link
Contributor

vitaut commented Jun 6, 2015

Thanks for the feedback. Currently bool is treated as an integer which might be somewhat confusing. I think it would be reasonable to change the default to the textual format and if anyone wants to print bool as a number they will still be able to use d or any other integer format specifier:

fmt::print("{}", true); // will print true (currently prints 1)
fmt::print("{:d}", true); // prints 1

This will be consistent with Python's behavior. What do you think?

@gnzlbg
Copy link
Author

gnzlbg commented Jun 6, 2015

I was expecting to remain consistent with std::cout where std::cout << true; prints 1.

fmt::print("{}", true); // prints 1 (as it currently does)
fmt::print("{:boolalpha}", true); // prints true (new behavior, opt-in)

where boolalpha is just a format specifier; boolalpha is really long, the first things I intuitively tried were b and B, but they are already used for binary.

I like Python's behavior a lot. IMO it is just a tradeoff of "breaking" existing code vs doing the "nice" thing. There is no right solution.

As long as there is an easy way to do it I am happy.

@chloe-zen
Copy link

Unary + turns bool to int easily, so bool printing as true/false is the better default.

@vitaut
Copy link
Contributor

vitaut commented Jun 6, 2015

@gnzlbg I thought about b too but, as you correctly pointed out, it is already used for binary and I'm a bit reluctant to add another specifier unless absolutely necessary. Since fmt::format is modeled after Python's str.format, I think it is reasonable to prefer consistency with the latter to IOStreams.

A more serious concern is breaking expectations of existing code, but this can be mitigated by a configuration option that returns the old behavior for projects that rely on it. In any case, since bool formatting is not documented at all, anyone who used it was using it at their own risk =).

@chipdude Thank you for the feedback too.

@gnzlbg
Copy link
Author

gnzlbg commented Jun 6, 2015

Since the project follows semantic versioning, it actually suffices to bump
up the API version to break the API for old projects. Doing that for this
"small" change is overkill, but one does not have to do that now. Providing
a macro to switch the behavior should be enough. When more compelling
reasons to break the API appear one could deprecate it or something. It's
your library, touch decision.

On Sunday, June 7, 2015, Victor Zverovich notifications@github.com wrote:

@gnzlbg https://github.com/gnzlbg I thought about b too but, as you
correctly pointed out, it is already used for binary and I'm a bit
reluctant to add another specifier unless absolutely necessary. Since
fmt::format is modeled after Python's str.format, I think it is
reasonable to prefer consistency with the latter to IOStreams.

A more serious concern is breaking expectations of existing code, but this
can be mitigated by a configuration option that returns the old behavior
for projects that rely on it. In any case, since bool formatting is not
documented at all, anyone who used it was using it at their own risk =).

@chipdude https://github.com/chipdude Thank you for the feedback too.


Reply to this email directly or view it on GitHub
#170 (comment)
.

@vitaut
Copy link
Contributor

vitaut commented Jun 11, 2015

Fixed in 9d09214. This will be in the next release (2.0) since there are other breaking changes that require major version change anyway.

@vitaut vitaut closed this as completed Jun 11, 2015
@gnzlbg
Copy link
Author

gnzlbg commented Jun 11, 2015

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants