Pre-RFC ~3655 Iteration 2 - Enhancements to Println and Dbg

language design
21

I would as well. The distinction I was making was "full expressions", as in anything that could possibly appear in expression context, including assignments. I personally don't think we should ever add those, and if we did it'd be within a delimiter, like {(expr):#x}.

22

Rather than making the format_args! grammar more complicated, I'd rather see improvements to the dbg! macro. format_args! is already so complicated that I have to look at the documentation every time I use one of the more niche features. They are certainly useful, but the syntax is optimized for conciseness, at the cost of its readability and intuitiveness.

The dbg! macro was made exactly for the use case this Pre-RFC tries to address. The only problem is that the format is not configurable, and it is quite verbose. With a way to hide the file and line number, and to use the normal Debug representation (:? rather than :#?), it would be more useful.

2 Likes
23

This doesn't solve the underlying problem here. dbg!, by design, provides approximately zero control over formatting, and while I think it'd be useful to support disabling the alternate syntax, that wouldn't make the proposal here redundant. Sometimes you want to format to somewhere else (e.g. stdout, or a file, or whatever's handy). Sometimes you want something more than just the expression.

That's the point. dbg! is meant to be a quick-and-dirty dump of information, and it wouldn't be feasible to make it sufficiently configurable to replace all the places where name=value would be useful in format arguments.

2 Likes
24

What if we'd instead give dbg!() the capability to select where things should go (similar to write!()?

// To where it goes now (stderr?)
dbg!(a, b, c)
// To stdout
dbg!(stdout: a, b, c)
// To file/writer (like write!())
dbg!(my_writer: a, b, c)

That would keep their use separate, doesn't require modifying format strings (if that's desired) and you can still really quickly search for any usage of dbg, or use a linter to prevent them from getting committed.

1 Like
25

Then we'd be making the simple single-purpose dbg! more complicated, by adding a feature that write! already has, in an effort to avoid extending the general-purpose format_args! (and thus write! and println! and so on).

2 Likes
26

I'm against extending format_args!, because:

  • the formatting strings are already complex with a very dense syntax made of sigils.
  • the formatting machinery is an overhead for all non-trivial executables, and Rust programs pay cost of new formatting features even if they don't use them.
  • As I've mentioned earlier, = format is not generally useful beyond programmer-facing printf-debugging junk output. It limits presentation to allowable variable names, has zero configurability. It's too crude for a user-facing UI, so it's a waste to complicate all formatting strings and add overhead to all programs for just minor cosmetic shortcut for printf-debugging.
4 Likes
27

This wouldn't have any runtime overhead as it would be handled entirely at compile-time. Both "{a:=}" and "a = {a}" would be emitted identically. Only with a width specifier would there be a possibility of runtime code being needed, but what a width specifier should even do hasn't really be discussed.

5 Likes
28

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.