Dbg!(): to optionally allow formatting

[Centril]

The arguments should match the return value.

They would do that:

let (a, b, c): (A, B, C);

dbg!(a): A
    (a): A

dbg!(a,): (A,)
    (a,): (A,)

dbg!(a, b): (A, B)
    (a, b): (A, B)

dbg!(a, b, c): (A, B, C)
    (a, b, c): (A, B, C)

There is perfect symmetry here between (a, b, c) and dbg!(a, b, c).

Moreover, it is useful, and expected.

The original dbg implementation also missed formatting options, was not accepted, therefore it is not a valid argument per se to state that my implementation is not in compliance with it.

It was discussed; [1], [2], [3], [4], [5].

I think multiple arguments are a more common use case than needing to specify formatting is. Also, from what I can tell, this would stabilize the format to a degree, which was explicitly a non-goal of dbg! (and specified in the documentation).

[scottmcm]

Since the debug output format is explicitly unstable and performance is not critical here (it’ll take longer as a human to look at the output), what about doing things like detecting large numbers of zero nibbles below the high bit and automatically displaying in hex (instead or additionally)?

[Centril]

what about doing things like detecting large numbers of zero nibbles below the high bit and automatically displaying in hex (instead or additionally)?

Pending specifics of the algorithm (e.g. not making it trigger a change when expected and not otherwise…) and how this detection is injected at compile time, it sounds at least intriguing.

[RoelKluin]

Maybe a sort of compromis is possible by concat!ng the first argument if it is a literal? I hope this could even be in compliance with Centril’s proposal as the dbg!() now does return both.

#[macro_export]
macro_rules! dbg {
    ($expr:expr) => {
        match $expr {
            expr => {
                eprintln!("[{}:{}] {} = {:#?}", file!(), line!(), stringify!($expr), &expr);
                expr
            }
        }
    };
    ($l:literal, $expr:expr) => {
        match $expr {
            expr => {
                eprintln!(concat!("[", file!(), ":", line!(), "] ",
                    stringify!($expr), " = ", $l), &expr);
                ($l, expr)
            }
        }
    }
}

then we could do

let (fmt, w) = dbg!("{}", 3);

// but this currently does not compile
let (a, b) = dbg!(1, 3);

The error in the 2nd is: formatting specifier missing. This may require evaluation of the literal: to see whether it can be concatenated, or not.

[repax]

I have to ask: what’s the motivation for all of this extra complexity? And why can’t you create an ad hoc macro that adds hex or binary formatting? It could also just be in a crate on crates.io.

I hardly ever need to deal with a long string of bytes represented in hex or binary. In my experience such values are one of the following:

• Really just a scalar, and decimal formatting is ok.
• Actually a struct – which should derive Debug to expose its components.
• An array of scalars.
• Very unusual. Use custom formatting.

[josh]

They would do that:

Not according to the original post in this thread, which seemed to ignore additional arguments and not return them.

[RoelKluin]

While using it, I found the stable dbg did not suffice my purpose, I created an ad hoc macro, and thought it was still simple, and was wondering why dbg did not support a little more. With my last proposal there will be some complexity in the code, but I would hope the evaluation of a literal will be optimized away. Fine, if you all disagree, then I’ll just create my macro locally or create a crate for this.

[Centril]

Not according to the original post in this thread, which seemed to ignore additional arguments and not return them.

I see; that would indeed be strange – the original dbg! implementation supports multiple arguments and returns all of them as a tuple tho…

Maybe a sort of compromis is possible by concat!ng the first argument if it is a literal? I hope this could even be in compliance with Centril’s proposal as the dbg!() now does return both.

So what I would do instead is to simply add another macro dbgf!(format, expr) for cases where the formatting is needed; it’s not a whole lot of complexity imo and lets us have both several arguments in dbg! as well as custom formatting in dbgf! (if it turns out custom formatting is actually a common need, which I’m not sure about along the lines of @repax’s argument).

It could also just be in a crate on crates.io.

So I think we tested this with https://crates.io/crates/dbg and it turned out that barely anyone used it for more than a year but once dbg! got added to std it was suddenly a big deal in the 1.32 release and talked a lot about in various places. (reddit, twitter, user forums, it was a big item in the blog post, and someone even made a python port of it… https://github.com/tylerwince/pydbg). The key lesson is that “it could also just be a crate” doesn’t work in this case because it’s too much hassle to import when you need it, but you still need it.

Fine, if you all disagree, then I’ll just create my macro locally or create a crate for this.

I’d accept a PR to the dbg crate if you want to add a dbgf! macro

[josh]

dbgf! sounds like a fine approach to me.

[mjbshaw]

dbg!(a): A
    (a): A

dbg!(a,): (A,)
    (a,): (A,)

Wow, that’s… nuanced, to say the least. A trailing comma in the macro invocation would change the resulting type? I find that really surprising given Rust’s history of accepting trailing commas in parameter lists to no affect.

[Centril]

Wow, that’s… nuanced, to say the least. A trailing comma in the macro invocation would change the resulting type? I find that really surprising given Rust’s history of accepting trailing commas in parameter lists to no affect.

It might be surprising, but also most likely unimportant / irrelevant. For the distinction to matter, you must depend on the resulting value being used and not thrown away e.g. by writing let x = dbg!(y,); In that unlikely event, you will get a type error that makes it clear why this happened. What is more likely to happen is you write dbg!(y,); in which case it does not matter whether Y or (Y,) is the resulting type because it is thrown away.

[RalfJung]

I find that really surprising given Rust’s history of accepting trailing commas in parameter lists to no affect.

But they do have an effect in parenthesis – (0,) and (0) are not the same thing. So this is consistent with tuples, which makes sense IMO.

[ExpHP]

That said, never before has a (stable) stdlib macro treated it’s input as anything other than a list of function arguments, except for stringify!.

I’m strongly against the tuple sugar, as I see no reason for tuples to receive special treatment here when they don’t receive it anywhere else.

[josh]

In general, rustfmt and Rust’s standard style encourages writing multi-line function invocations with a comma after each argument, including the last. rustfmt can’t always insert or remove trailing commas in macros, because it doesn’t know whether the macro will treat commas as significant, but I think making the trailing comma significant is a bad idea. If you want to invoke dbg! on a 1-tuple, I think that should be spelled dbg!((x,)).

[Aloso]

Also, I find it confusing that

dbg!{ a, }

returns a tuple.

[ExpHP]

I also just discovered the fact that dbg! uses {:#?} instead of {:?}. Doesn’t this make it extremely ill-equipped for tuples to begin with? It is far more difficult to scan related values vertically than horizontally because it encodes multiple types of information into the same channel of output.

[src/main.rs:4] (x, y) = (
    2,
    1
)
[src/main.rs:4] (x, y) = (
    2,
    2
)
[src/main.rs:4] (x, y) = (
    2,
    3
)
[src/main.rs:4] (x, y) = (
    40,
    1
)
[src/main.rs:4] (x, y) = (
    40,
    2
)
[src/main.rs:4] (x, y) = (
    40,
    3
)
[src/main.rs:4] (x, y) = (
    800,
    1
)
[src/main.rs:4] (x, y) = (
    800,
    2
)
[src/main.rs:4] (x, y) = (
    800,
    3
)

This gets even worse if you have multiple dbg!s with tuples; with {:?} you have a chance that differences in length of the line number/filename/expression could help make it easier to discern between output from the two, but with {:#?} you need to look above at previous lines to make sense of things.

…so basically I really don’t see why we’re even considering trying to facilitate dbg!((a, b)) when it produces such terrible output to begin with.

[Centril]

…so basically I really don’t see why we’re even considering trying to facilitate dbg!((a, b)) when it produces such terrible output to begin with.

It wouldn’t be rendered that way…

[dhm]

This gets even worse if you have multiple dbg! s with tuples; with {:?} you have a chance that differences in length of the line number/filename/expression could help make it easier to discern between output from the two, but with {:#?} you need to look above at previous lines to make sense of things.

…so basically I really don’t see why we’re even considering trying to facilitate dbg!((a, b)) when it produces such terrible output to begin with.

Indeed, I really don’t understand this weird exception to Rust explicit tupling. If we wanted Python-like *args with macros (because we can), we should have gone down that path a long time ago. This just breaks the consistency of ::std macros.

For the record, I think most people would have expected dbg! to be like this.

[josh]

Could we please add column numbers to distinguish where multiple values on the same line come from?

[Centril]

Seems easily done if necessary… The nice thing about the macro is that the output format is highly unstable