Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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...)


There's a library for that: 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.


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).


IntelliJ provides syntax highlighting for common Rust macros.


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.


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.


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 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). No need to change how the language works when you can download or build a library that suits you.


> 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.


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).


> 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).


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).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: