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.
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,)).
Also, I find it confusing that
dbg!{ a, }
returns a tuple.
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.
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.
Could we please add column numbers to distinguish where multiple values on the same line come from?
Seems easily done if necessary… The nice thing about the macro is that the output format is highly unstable 
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.