Skip to content

want version of dbg! using {:?} not {:#?} #82778

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
ijackson opened this issue Mar 4, 2021 · 6 comments
Closed

want version of dbg! using {:?} not {:#?} #82778

ijackson opened this issue Mar 4, 2021 · 6 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@ijackson
Copy link
Contributor

ijackson commented Mar 4, 2021

I find the pretty-printing output from dbg! more annoying than helpful and I am privately using a version of this macro that doesn't pretty-print.

When I discussed this on the Discord several people also shared the same opinion about dbg!'s pretty-printing. (No-one really said they liked it, although that's a biased sample...) This suggests that there would be demand for a compact output version in std. While the docs for std::dbg! say the output format cannot be relied on, ISTM that changing it to remove the # would be rude (and controversial). So I suggest providing a compact version in parallel. I suggest the name dbgc! for "debug compact" but I am of course happy with whatever colour bikeshed.

If the libs team thinks this would be welcome, I will make an MR for it. If the libs team don't like this idea then fine, I can keep using my clone-and-hack :-).

While I'm here I notice that the docs suggest committing calls to dbg! is a bad idea. grepping my own codebase showed that I agree with one significant exception: I use it liberally in tests. I think it's great there and the docs could probably mention that as a good use case.

@ijackson
Copy link
Contributor Author

ijackson commented Mar 4, 2021

@rustbot modify labels +C-feature-request +T-libs

@rustbot rustbot added C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Mar 4, 2021
@cuviper
Copy link
Member

cuviper commented Mar 11, 2021

Another bikeshed possibility is to have an alternate pattern added to dbg!, perhaps using a (non-expression) sigil prefix. There's no obvious choice to me unless we flip it -- e.g. make dbg!(foo) plain and let dbg!(# foo) be pretty, but even that probably conflicts with expression attributes.

@ChrisJefferson
Copy link
Contributor

If someone wanted to try this out as a package first, I'd personally use it.

@joshtriplett
Copy link
Member

joshtriplett commented Mar 16, 2021

@ijackson wrote:

(No-one really said they liked it, although that's a biased sample...)

It tends to depend on the nature of the output you have. When printing a complex structure, especially a nested structure, the # output can be wildly useful. When printing an array of bytes, on the other hand, I rarely want the bytes listed one-per-line. (Though that can sometimes be a sign that a BString/BStr would help, as well.)

It might be worth considering improvements to the {:#?} formatting, for specific cases where it produces suboptimal results. As one potential example, we could potentially use specialization to provide better Debug output for Vec<u8>.

All that said, we have both formats for a reason, and it's not unreasonable to want access to both. The question then becomes, how often do people want a dbg! with the non-# output, and is that worth an abbreviated name?

It's also worth noting that we could provide a macro with a less-abbreviated name, and people who want a more abbreviated version could use std::debug_compact as dbgc (for instance). So there are two questions here: should we provide this macro, and should we provide it under an abbreviated name?

@cuviper I personally don't think it'd be a good idea to add a semi-magic argument to the `dbg! macro to change the output format.

While I'm here I notice that the docs suggest committing calls to dbg! is a bad idea. grepping my own codebase showed that I agree with one significant exception: I use it liberally in tests. I think it's great there and the docs could probably mention that as a good use case.

This seems reasonable, and I'd be happy to r+ a PR adding such a note to the documentation.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 15, 2021
…iplett

dbg macro: Discuss use in tests, and slightly clarify

As discussed in a tangent in rust-lang#82778.

I chose to use [semantic newlines](https://rhodesmill.org/brandon/2012/one-sentence-per-line/) in the source text but I don't mind reformatting it.
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 15, 2021
…iplett

dbg macro: Discuss use in tests, and slightly clarify

As discussed in a tangent in rust-lang#82778.

I chose to use [semantic newlines](https://rhodesmill.org/brandon/2012/one-sentence-per-line/) in the source text but I don't mind reformatting it.
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 15, 2021
…iplett

dbg macro: Discuss use in tests, and slightly clarify

As discussed in a tangent in rust-lang#82778.

I chose to use [semantic newlines](https://rhodesmill.org/brandon/2012/one-sentence-per-line/) in the source text but I don't mind reformatting it.
@Milo123459
Copy link
Contributor

Another bikeshed possibility is to have an alternate pattern added to dbg!, perhaps using a (non-expression) sigil prefix. There's no obvious choice to me unless we flip it -- e.g. make dbg!(foo) plain and let dbg!(# foo) be pretty, but even that probably conflicts with expression attributes.

I'm looking to implement this, and I personally think dbg!(# foo) should be the un-prettyprinted version.

Also - am I good to claim?

@Dylan-DPC
Copy link
Member

Closing this as it is better suited to be trialed as a crate (there are a few present already now but weren't around at the time this issue was created).

@Dylan-DPC Dylan-DPC closed this as not planned Won't fix, can't repro, duplicate, stale Jan 15, 2024
btwiuse pushed a commit to btwiuse/gdbg that referenced this issue Jan 16, 2024
Since the same feature has been added to gstd (gear-tech/gear#3610)
this crate should've been deprecated

However, the compact version of dbg! proposed in rust-lang/rust#82778
does look better

So let me repurpose this crate as the compact implementation of dbg! for gear smart contracts
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants