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

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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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