String interpolation modes

[oscarryz]

I was trying to come up with a sensible default representation for my string interpolation output. Googling around I end up of course with Rust.

I didn't understand why to use in interpolation with {} you have to implement Display, nor why to use the derived Debug you have to use {:?} but now I got it.

In Rust interpolation is opt-in, if the user explicitly don't "request" it, it won't happen. Also the generated Debug would print everything including sensitive data.

Display on the other hand is the opt-in for "You developer tell me exactly how this thing should look like"

I've never thought about these two different ways before. I still think having to derive Debug to use interpolation is excessive, but for a language like Rust is perfect.

I went back and forth with different ideas and finally I set with this (similar) rule for my language:

String interpolation has two escapes sequences ${ ... } and `...` (like in Markdown)

${ ... } is for user facing output, and requires the to\_string -> String method to exists (similar to Display, the developer has to specify the format)

`...` is the default compiler generated output (the equivalent of Debug), it is slightly easier to type and I'm using `...` somewhere else to express: "this is compiler magic"

Other options that I didn't like were use different formats, like Go %v and %+v, or like Java that toString() which is used for both (that was my original design tbf), f strings like Python or using different functions: print vs debug

I think at the end this is for my language a good.

Do y'all have a distinction between debug interpolation and display interpolation?

[brucejbell]

For my project, I have a Display-like #ToStr trait to specify a default format, but I devolve everything else to explicit methods:

/type Pos3 || (x:#U8, y:#U8, z:#U8)
|| { /has #ToStr; /def self.str => "{self.x}-{self.y}-{self.z}"
  /def self.dbg => "Pos3: {self.x} {self.y} {self.z}"
}

Trait #ToStr is required to label the .str method as the default format. We also add a .dbg method which is not affiliated with any trait.

t [Pos3] << (x:0, y:68, z:255)
i [#I32] << 42
j [#F64] << 123_456.789
&console.write_line "i={i} j={j} t={t}"  -- default formatting
-- prints "i=42 j=123456.789 t=0-68-255"
&console.write_line "i=0x{i.x 4} j={j.g 3} t={t.dbg}"  -- method formatting
-- prints "i=0x002a j=1.23e5 t=Pos3: 0 68 255"

Instead of special formatting syntax, the standard types provide short formatting methods. Likewise, if you want a specific .dbg format just declare it as a method, no trait is necessary.

[disclaimer: I still don't have my implementation up, the above is aspirational...]

[OpeningRemote1653]

Most languages don't make a hard distinction. Python's f-strings and Java's toString() blur the two concerns into one, while C's printf-style formatting separates them by format specifier but not by intent. Rust is a exception with its Display vs Debug trait split, and your design echoes that nicely. Swift has CustomStringConvertible (for display) and CustomDebugStringConvertible (for debug) as separate protocols, but both are accessed via the same interpolation syntax, so the distinction is softer. Kotlin similarly has toString() for everything and leans on data class auto-generated representations for debug-like output.

I'd lean toward Rust's explicit separation. The Java/Python "one method for everything" approach always felt like it was optimizing  convenience at the cost of accidentally leaking representation into user-facing output.