Rust 1.58.0 | Hacker News Reader

Rust 1.58.0

blog.rust-lang.org

101 points0xedb16 comments

Being able to use formatting patterns similar to python sounds really awesome. It makes formatting with long formatting strings really a lot more expressive and more readable.

Yet they stopped short of allowing arbitrary expressions in string formatting. (Good!)

The Rust team is striking all of the right balances between convenience and safe ergonomics.

You can’t even access a member though.

> Format strings can only capture plain identifiers, not arbitrary paths or expressions.

Why?

Because arbitrary expressions open a pandora box that complicates everything touching them.

For example, expressions can be strings, so now you have strings inside strings, and the strings may even contain further levels of nested formatting strings. This would make correct tokenization of Rust quite difficult, and out of reach of most syntax highlighting tools.

So the next question is why not allow only some "simple" expressions. It would require teaching users which expressions are allowed and which aren't. The rule that only a single identifier is allowed is both simple to parse, and simple to teach.

It's hardly a rare feature. Everything from C# to JS has it these days, so I think "out of reach of most syntax highlighting tools" might be overstating things a bit. It can't be that hard.

You don't have to allow nested strings either; Python's f-strings don't, they always parse as a regular string too (well, you can use a 'single-quoted string' inside a "double-quoted f-string").

You can have nested quotes already, arbitrarily many levels deep.

Can always lookup and check the RFC: https://rust-lang.github.io/rfcs/2795-format-args-implicit-i...

This is a nice step.

Now they should allow expressions in addition to just names and apply it to all string literals.

This can never happen with regular string literals. String literals have the type `&'static str` but formatting returns a `String`.

Perhaps something could be done with compile-time code execution, but the bigger problem is that it wouldn't be backwards-compatible. Currently "{foo}" is a perfectly valid string that doesn't evaluate anything.

In truth, it probably requires something like `f"foo {bar}"`

Nice work! Looks like I have some code updates to do.

index or format specs are ok, but capturing variables is a bad idea, visually bloats the string, it becomes unreadable

It's not a bad idea. Think of the variable name as documentation.

i maintain, it is a bad idea

i used to use it with C#, so i talk with experience

but what ever.. this is rust we are talking about, it's sad that they decided to follow Scala and bloat their language

Reply on news.ycombinator.com