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

Cleaner dbg! macro without alternate formatting #115589

Open
rsalmei opened this issue Sep 6, 2023 · 2 comments
Open

Cleaner dbg! macro without alternate formatting #115589

rsalmei opened this issue Sep 6, 2023 · 2 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@rsalmei
Copy link

rsalmei commented Sep 6, 2023

Hello!
I have to say I don't love the dbg! macro. It pollutes the output unnecessarily, and could easily be way cleaner.
Personally, I think it is a missed opportunity. It actually doesn't use debug formatting {:?}, it uses alternate debugging {:#?} I'm not sure why. This, unfortunately, makes everything get a lot more newlines than needed. So, we get this:

[src/lib.rs:105] &order = [
    8,
    14,
    13,
]
[src/lib.rs:105] &order = [
    6,
    14,
    5,
    4,
    3,
    2,
]
[src/lib.rs:9] &win = [
    8,
    14,
    13,
]

instead of simply this:

[src/lib.rs:105] &order = [8, 14, 13]
[src/lib.rs:105] &order = [6, 14, 5, 4, 3, 2]
[src/lib.rs:9] &win = [8, 14, 13]

Similarly, for structs it prints one field per line and gets very verbose.

I imagine people use the alternate formatting very sparingly, only when something gets so complex that it warrants the added pollution, I know I rarely have used it. In the vast majority of cases, we all use {:?} the standard debug formatting. So, why adopt the alternate one in the dbg! macro?

I'd like to ask you to please reconsider it. It is a single character change.
Thank you.

$crate::eprintln!("[{}:{}] {} = {:#?}",
$crate::file!(), $crate::line!(), $crate::stringify!($val), &tmp);

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Sep 6, 2023
@fmease fmease added C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 6, 2023
@fmease fmease removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Sep 29, 2023
@ian-h-chamberlain
Copy link
Contributor

+1, I think the {:?} format is more often what I want especially for debugging things like small Vecs or tuples, (or Vecs of tuples, especially!) and the long-form output is often hard to read.

I looked around a little for prior proposals to see if this seems like to be accepted or has been asked before.


FWIW — the RFC for dbg! explicitly did not prescribe/stabilize a specific output format, probably in case a change like this was requested: https://rust-lang.github.io/rfcs/2361-dbg-macro.html#unstable-output-format

It seems that dbg! in its original form had more options for controlling the formatting: rust-lang/rfcs#2173 , but that was eventually superseded by what is implemented today. The first RFC suggested the use of an environment variable to control the output format (but was eventually closed in favor of the simpler, always-the-same-format approach).

A couple relevant comments in that original discussion:
rust-lang/rfcs#2173 (comment)
rust-lang/rfcs#2173 (comment)

rust-lang/libs-team#125 (for #103334) seems like a related ACP although it seems to focus mainly on stripping out the file/line number, which isn't quite the same as this request...


Something occurred to me as a possible enhancement for cases where {:#?} format is desired, but I am not sure if there is precedent for this or if it's a little too "out there" - but the dbg! could be changed to accept additional tokens / sigils, e.g.

dbg!(x); // prints with {:?} format
dbg!(#x); // prints with {:#?} format (current behavior of `dbg!(x)`)

A quick mockup of that: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b9276544d7d61cea1d7cd08ffe233a54

The newer (accepted) RFC2361 specifically wanted to avoid giving users control over the output, probably because it could easily invite a much longer discussion about what's supported ("why not padding?" "why not support the whole {} format mini-language?"): https://rust-lang.github.io/rfcs/2361-dbg-macro.html#a-simple-macro-without-any-control-over-output

This kind of thing could easily be implemented as a crate, or in fact users could opt to install the original RFC2173 implementation! https://crates.io/crates/dbg

However I think a big part of the value of the dbg macro is the fact that it's included in the standard library, so personally I'd love to see this change implemented without requiring a 3rd party crate. The original RFC mentions this as well: https://github.com/Centril/rfcs/blob/rfc/quick-debug-macro/text/0000-quick-debug-macro.md#not-useful-as-a-crate


So, in summary, these seem like the likely/possible outcomes - but probably would need the libs team to make a call as well here:

  • Do nothing (the easy option)
  • Reopen discussion about controlling output format – might require a new RFC to amend RFC2361 or at minimum an ACP I think?
  • Change the default format with no option to control – might require an ACP and/or some kind of community poll to see if this is actually desirable behavior to most users?

@rsalmei
Copy link
Author

rsalmei commented Dec 24, 2023

Thank you very much for your considerations!
You've brought up some amazing points I wasn't aware of.

dbg!(x); // prints with {:?} format
dbg!(#x); // prints with {:#?} format (current behavior of `dbg!(x)`)

I loved this suggestion and its impl! I think it would nicely fix it for almost everybody 👏

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 Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants