Hacker News Reader

Comment by megumax | Hacker News Reader

It's a nice Quality of Life addition, that I would like to see with C++ as well.

I wish they don't implement f-strings and s-strings, at least for now. Even if they are more ergonomic than the `format!` and `String::from`, they hide a memory allocation which is not really indicated in a language like Rust and would be really weird in a context without an allocator. The only solution to this would be `const` evaluation of this, but that would restrict their use to `const` environments, so mostly unusable.

View on HN

As a person involved in this space, if there's ever an RFC for full-on f-strings there's a good chance that I'd be the one who writes it, and I can tell you for certain that I would not make `f"foo"` incur an allocation; it would return a std::fmt::Arguments rather than a String.

just for clarity's sake: you mean an RFC for rust and not c++ right?

From the syntax, yes

I mean, that ship's basically sailed. People are too lazy even to take `std::string_view` instead of `std::string&`, trying to avoid pointless allocations and clones with any API but your own is almost a fool's errand at this point.

I think the issue with string_view is less laziness and more recency: most libraries still need to support C++ versions prior to C++17. Rust had the advantage that slices were there from day one.

For example, Bloomberg is still on their transition to C++14, let alone C++17.

"C++11/14 at Scale: What Have We Learned?"

https://www.youtube.com/watch?v=E3JG2Ijjei4

I don't think it's just recency either, it's just incredibly easy to shoot yourself into the foot with string_view when the language has no way of checking that the pointed to memory is actually valid. People moved to smart pointers for good reasons and string_view just undoes all of that.

Yeah, it was a bad decision.

While using C++, adding something like gsl to the toolbox is worth gold, and also enabling bounds checking even in release (really, most of the time it hardly matters to the application users).

I was happy to see `fmt` make it into C++20 as `std::format`, it's a great library

C++23 is getting print if it goes according to plan.

I feel the same way, I think f-strings and s-strings are going a bit too far for the sake of convenience.

I think it would be possible in C++, but it would be something that is more generic than f-strings in Python. For example, `f"Name: {name}, age: {age}"` could maybe expand to `"Name: {}, age: {}", name, age`, so you still need to pass it to some variadic function that then can decide what to do with it, instead of only being able to format strings.

How do f strings hide memory allocations more than format!?

f-strings would be part of Rust's grammar. `format` macro isn't available in `core` crate, but it is in `alloc` crate, so it needs to allocate memory.

f-strings on other hand would be pretty weird. Would `f"5"` return a &'static str or a String?

I know it would need to allocate memory, but from a user perspective that allocation isn't less visible when using f strings instead of the format macro.

In your example I would return a String and generate a warning, because the f of the string isn't used.

If it was part of Rust the language it can't create Strings because String isn't part of the language, nor even a "langitem". The core Rust language has no idea there's such a thing as a String

str (and thus &str) is part of the language, it's a built-in primitive type like i64 or bool, but String is just a struct the alloc crate brings into existence and so it may not be available.

I see.

Though could this work by the language feature just working like a Macro? Code without alloc using f strings just wouldn't compile then

In theory f-strings could act as the format_args! macro, not the format! macro. While the latter produces a String, the former produces a std::fmt::Arguments, and does not need to allocate memory (it lives in core).

Reply on news.ycombinator.com