3 ms·

Example reminds me: I love Rust, but every decent programming language in 2019 should have actual string interpolation (the "Hello ${expression}" kind). It's ju

Example reminds me: I love Rust, but every decent programming language in 2019 should have actual string interpolation (the "Hello ${expression}" kind). It's just so much nicer to read and write, and it doesn't come with any downsides besides some slight, local compiler complexity. (I have raised it on the forums already...)

hombre_fatal 7y ago
I prefer Rust's: format!("{a} {c} {b}", a="a", b='b', c=3) In real world projects, you will often transform at interpolation site which is better with Rust's format! syntax since it won't clutter the inline string. Not something I think is worth bike-shedding further.
- xixixao 7y ago
  Ok, how about we agree both mine and your concerns are equivalently important? With real interpolations, you can do: a = "a" b = 'b' c = 3 "{a} {c} {b}" Your concern is addressed, with real interpolations, already.
  - db48x 7y ago
    It's a perfectly valid complaint, though I don't think it's all that critical. For debugging, the `dbg` macro is the way to go, so you can skip string interpolation for that entirely (see https://doc.rust-lang.org/std/macro.dbg.html https://doc.rust-lang.org/std/macro.dbg.html for details). And when you do want to use string interpolation, you can always grab a crate such as interpolate or any of the others. (https://crates.io/search?q=interpolate https://crates.io/search?q=interpolate). No need to change how the language works when you can download or build a library that suits you.
oconnor663 7y ago
> slight, local compiler complexity I think the biggest piece of added complexity would be that String would need to be a lang item, giving the compiler special knowledge about it. Currently Vec and String are plain library types, so conceptually this would be a pretty big change.
- xixixao 7y ago
  I'm not familiar with Rust compiler internals (I am familiar with other compilers though), but there are many ways to implement this, which could happen in a stage before types are considered (for example the expression `"Hello {a + b}"` could be first internally transformed to `format!("Hello {}", a + b")` - more complexity ensues, but it is doable).
JoshTriplett 7y ago
> it doesn't come with any downsides One downside: if you move from interpolating a simple variable name to an expression, then you have to move it out-of-line from the string again (or you have to support interpolating arbitrary expressions into strings, which gets really painful and makes it hard for editors to check/highlight/etc).
- xixixao 7y ago
  I am absolutely advocating for arbitrary expressions, I should have made that even clearer in my example. Again, the burden is on the editors/compiler, but it massively simplifies life for the developer using the language. check/highlight is supported just fine for many languages that have this feature (it's likely that parts of Rust already require similar editor implementations for some other parts of its syntax).
nicoburns 7y ago
There's a library for that: https://github.com/ct-austin/ifmt https://github.com/ct-austin/ifmt In general, a lot of things that are language features in higher-level languages, can and are implemented as libraries in Rust. It's possible that this will make it into the standard library at some point.
- xixixao 7y ago
  The reason to include it in the core language, besides potentially not requiring the additional syntax of a macro call, is what another commenter pointed out: You want editor support (click to definition, syntax highlighting, typing).
  - nicoburns 7y ago
    IntelliJ provides syntax highlighting for common Rust macros.

hombre_fatal 7y ago

I prefer Rust's: format!("{a} {c} {b}", a="a", b='b', c=3) In real world projects, you will often transform at interpolation site which is better with Rust's format! syntax since it won't clutter the inline string. Not something I think is worth bike-shedding further.

xixixao 7y ago
Ok, how about we agree both mine and your concerns are equivalently important? With real interpolations, you can do: a = "a" b = 'b' c = 3 "{a} {c} {b}" Your concern is addressed, with real interpolations, already.
- db48x 7y ago
  It's a perfectly valid complaint, though I don't think it's all that critical. For debugging, the `dbg` macro is the way to go, so you can skip string interpolation for that entirely (see https://doc.rust-lang.org/std/macro.dbg.html https://doc.rust-lang.org/std/macro.dbg.html for details). And when you do want to use string interpolation, you can always grab a crate such as interpolate or any of the others. (https://crates.io/search?q=interpolate https://crates.io/search?q=interpolate). No need to change how the language works when you can download or build a library that suits you.

oconnor663 7y ago

> slight, local compiler complexity I think the biggest piece of added complexity would be that String would need to be a lang item, giving the compiler special knowledge about it. Currently Vec and String are plain library types, so conceptually this would be a pretty big change.

xixixao 7y ago
I'm not familiar with Rust compiler internals (I am familiar with other compilers though), but there are many ways to implement this, which could happen in a stage before types are considered (for example the expression `"Hello {a + b}"` could be first internally transformed to `format!("Hello {}", a + b")` - more complexity ensues, but it is doable).

JoshTriplett 7y ago

> it doesn't come with any downsides One downside: if you move from interpolating a simple variable name to an expression, then you have to move it out-of-line from the string again (or you have to support interpolating arbitrary expressions into strings, which gets really painful and makes it hard for editors to check/highlight/etc).

xixixao 7y ago
I am absolutely advocating for arbitrary expressions, I should have made that even clearer in my example. Again, the burden is on the editors/compiler, but it massively simplifies life for the developer using the language. check/highlight is supported just fine for many languages that have this feature (it's likely that parts of Rust already require similar editor implementations for some other parts of its syntax).

nicoburns 7y ago

There's a library for that: https://github.com/ct-austin/ifmt https://github.com/ct-austin/ifmt In general, a lot of things that are language features in higher-level languages, can and are implemented as libraries in Rust. It's possible that this will make it into the standard library at some point.

xixixao 7y ago
The reason to include it in the core language, besides potentially not requiring the additional syntax of a macro call, is what another commenter pointed out: You want editor support (click to definition, syntax highlighting, typing).
- nicoburns 7y ago
  IntelliJ provides syntax highlighting for common Rust macros.