allow multiple args to dbg!(..)

[llogiq]

This closes #59763

[Centril]

I think a better implementation of this, as I originally envisaged, was to have each part of the tuple on a separate line for better readability. Moreover, dbg!(1,) and dbg!(2, 3,) is supported by this change whereas it is not by your implementation.

[Centril]

r? @alexcrichton

[Centril]

Moreover, the UI tests for dbg! should be extended to cover the new behavior once we settle on a behavior, assuming we want to make this change.

[alexcrichton]

r? @SimonSapin

I think you authored the original RFC, so you're probably best to look at this

[SimonSapin]

In the RFC, I specifically proposed not doing this:

https://github.com/rust-lang/rfcs/blob/master/text/2361-dbg-macro.md#accepting-a-single-expression-instead-of-many

I think it creates an undesirable “discontinuity”: if dbg!(x, y, z) returns the 3-tuple (x, y, y) and dbg!(x, y) returns the 2-tuple (x, y) (and dbg!() returns the zero-tuple ()) then the consistent continuation is that dbg!(x) returns the 1-tuple (x,). But it has been stabilized as returning x, and a 1-tuple is probably less convenient anyway.

I can’t find it again, but I vaguely remember an argument that you could look at dbg!(x) as dbg! (x), and (x) by itself is x with unnecessary parens, not a tuple. But I disagree with this framing: the foo!(…) syntax of expression-position macro invocation is much more similar to function call syntax than to tuple syntax. (Using a 1-tuple to represent the arguments of a single-argument function appears again in the desugared notation for the Fn(T) trait, which is Fn<(T,)>.)

This PR seems to be going for emulating tuple syntax: it makes dbg!(x,) behave differently than dbg!(x) and return (x,) instead of x. But in a function call, a trailing comma after arguments is not significant. I think we should not make it significant in a function-like macro that takes comma-separated expressions as arguments.

---

TL;DR: I feel I would still prefer that dbg!(…) only accepts one (or zero) expression, and that making it return a tuple involves passing it an actual tuple value.

That said, is there consensus except for me that the convenience of debugging multiple values with fewer sigils is worth accepting this weird inconsistency?

If so, I’d prefer we embrace the inconsistency and make dbg!(x,) the same as dbg!(x). And maybe the filename and line number should not be repeated for every element of the tuple?

CC @rust-lang/libs

[Centril]

I can’t find it again, but I vaguely remember an argument that you could look at dbg!(x) as dbg! (x), and (x) by itself is x with unnecessary parens, not a tuple.

Yes, that is the framing I was going for. It provides a good internal consistency. Perhaps not the one you want, but I think it works well in practice to do what the users wants 99% of the time.

This PR seems to be going for emulating tuple syntax: it makes dbg!(x,) behave differently than dbg!(x) and return (x,) instead of x. But in a function call, a trailing comma after arguments is not significant. I think we should not make it significant in a function-like macro that takes comma-separated expressions as arguments.

What is the failure mode here? i.e. in what way do you think this will trip users up?

Note that if you write dbg!(x); or dbg!(x,); it will not matter that you actually received back a tuple as the semicolon turns the type into () in any case.

To actually have a problem, you need to actually use the result:

let x = dbg!(x,);

(x must still be passed along to have a problem)

I think this is unlikely and is only probable as the result of a typo. When it happens the compiler already gives a good error message:

fn main() {
    let _: u8 = dbg!(1,);
}

results in:

error[E0308]: mismatched types
  --> src/main.rs:18:9
   |
18 |         ($(dbg!($val)),+,)
   |         ^^^^^^^^^^^^^^^^^^ expected u8, found tuple
...
23 |     let _: u8 = dbg!(1,);
   |                 -------- in this macro invocation
   |
   = note: expected type `u8`
              found type `({integer},)`

If so, I’d prefer we embrace the inconsistency and make dbg!(x,) the same as dbg!(x). And maybe the filename and line number should not be repeated for every element of the tuple?

Note that this only makes the macro more complex, not less. One good advantage of this PR is that it provides a simple implementation that should also be simple to explain: simply remove dbg! and the thing you have without is the value you get back out and of that type. This rule would have zero exceptions with this PR.

[Centril]

As for whether to accept multiple arguments or not, I think that the purpose of dbg! is quick and convenient debugging. To not accept multiple arguments goes against that as the user must actively remember that they can pass a tuple instead (and it gives less readable output). That a diagnostic was suggested in #59763 is in my mind evidence that accepting multiple arguments is intuitive and expected.

[BurntSushi]

If this PR is accepted, is the type of dbg!(a, b) and dbg!((a, b)) the same?

I do agree with @SimonSapin that if we're going to allow multiple arguments, then the trailing comma in the case of the first argument should behave like a function call. While let x = dbg!(y,); is unlikely to happen in practice, something like this is much more feasible:

let x = dbg!(
    some_long_single_argument_expression,
);

And if that doesn't work---regardless of whether we permit multiple arguments or not---I would honestly be pretty surprised. I'd expect things like this to work as expected as well:

let x = dbg!(
    some_long_single_argument_expression,
    another_long_single_argument_expression,
);

I don't have too many strong opinions on whether we permit multiple arguments. It does honestly seem nice, and the case of wanting a unit tuple is a bit weird/rare anyway, so if you did need that, you'd just have to get used to writing dbg!((x,)) I guess.

[Centril]

• In particular, dbg!(x) returns x, not (x,).

@SimonSapin You mean dbg!(x,) here, right?

[llogiq]

I read this as dbg!(x,) == dbg!(x) (yes, that means for 1-tuples we need double braces).

[SimonSapin]

Ah yes, that was a typo. Fixed.

[SimonSapin]

I’m personally still undecided (and forgot to bring it up in the meeting) whether it’s better if the file name and line number are printed once per macro call or once per argument.

[Centril]

@SimonSapin Since that's not part of the stable guarantees it seems to me that we can do the simple thing now and iterate / "feel" our way through.

[SimonSapin]

Sure, it’s not set in stone and we can change our minds later. I think it’s still worth discussing now, though! Do you have thoughts either way?

[Centril]

Do you have thoughts either way?

It's tricky... on the one hand, having output like:

[src/main.rs:2] a = 1
[src/main.rs:2] b = 2
[src/main.rs:2] c = 3

feels nicely aligned... on the other it feels repetitive.

A sketch for an alternative for multi-argument output:

[src/main.rs:2]
[ a = 1
[ b = 2
[ c = 3

[llogiq]

I've implemented the libs team's suggestions as @SimonSapin wrote them up. I did not yet change the output of the macro, we can iterate on that later.

[llogiq]

@SimonSapin if you are OK with this I'd like to land this as is now and iterate on the output in a follow-up PR.

[SimonSapin]

Looks good, thanks!

@bors r+

[bors]

📌 Commit b641fd3 has been approved by SimonSapin

[bors]

⌛ Testing commit b641fd3 with merge 33fe113...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: SimonSapin
Pushing 33fe113 to master...