Skip to content

DebugTuple builder needs more options controlling its behaviour #1448

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

Open
nagisa opened this issue Jan 6, 2016 · 4 comments
Open

DebugTuple builder needs more options controlling its behaviour #1448

nagisa opened this issue Jan 6, 2016 · 4 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@nagisa
Copy link
Member

nagisa commented Jan 6, 2016

DebugTuple should have options controlling how to output tuples with 0 and 1 element.

Currently if 0 fields are provided, only the name passed into debug_tuple is printed. Would be nice if there was option to print {name}().

Currently if only 1 field is provided, trailing comma is not printed. There should be an option to add one: (value,).

These could be added as option setters on the DebugTuple builder. E.g. fn empty_tuple(bool) and fn trailing_comma(bool).

That would make debug_tuple actually usable to print tuples.

@nagisa
Copy link
Member Author

nagisa commented Jan 6, 2016

cc @tsion

@solson
Copy link
Member

solson commented Jan 6, 2016

This explanation might be redundant, but I see two separate issues:

  • A named tuple with no elements prints Name rather than Name(). Admittedly, the latter doesn't currently exist in Rust, but it might be added later like struct Name {} was, and the former Name isn't a tuple struct at all. This might be considered an actual bug.
  • An un-named tuple with 0 or 1 elements prints nothing or (elem) (with no trailing comma), respectively. This is basically a feature request to make debug_tuple work for anonymous tuples.

@sfackler
Copy link
Member

sfackler commented Jan 6, 2016

Tuples already have debug implementations - what external implementations would exist?

@nagisa
Copy link
Member Author

nagisa commented Jan 6, 2016

@sfackler we’re trying to use in pretty-printing MIR representation for tuple aggregates. That’s at least one use case.

bors added a commit to rust-lang/rust that referenced this issue Jan 7, 2016
r? @nikomatsakis

(Related issue about `debug_tuple` at rust-lang/rfcs#1448.)

```rust

fn main() {
    let _x = ();
}
```

```diff
--- empty_tuple-old.mir	2016-01-06 16:04:24.206409186 -0600
+++ empty_tuple-new.mir	2016-01-06 14:26:17.324888585 -0600
@@ -1,13 +1,13 @@
 fn() -> () {
     let var0: (); // _x
     let mut tmp0: ();

     bb0: {
-        var0 = ;
+        var0 = ();
         Some(goto -> bb1);
     }

     bb1: {
         Some(return);
     }
 }
```
@nrc nrc added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Aug 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

4 participants