9 ms·

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

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.

pie_flavor 5y ago
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.
- johncolanduoni 5y ago
  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.
  - pjmlp 5y ago
    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 https://www.youtube.com/watch?v=E3JG2Ijjei4
  - ATsch 5y ago
    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.
    - pjmlp 5y ago
      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).
jackosdev 5y ago
I was happy to see `fmt` make it into C++20 as `std::format`, it's a great library
- pjmlp 5y ago
  C++23 is getting print if it goes according to plan.
gefhfffh 5y ago
How do f strings hide memory allocations more than format!?
- megumax 5y ago
  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?
  - gefhfffh 5y ago
    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.
    - tialaramex 5y ago
      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.
      - gefhfffh 5y ago
        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
  - kibwen 5y ago
    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).
deleted 5y ago
[deleted]
simias 5y ago
I feel the same way, I think f-strings and s-strings are going a bit too far for the sake of convenience.
kibwen 5y ago
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.
- accountofme 5y ago
  just for clarity's sake: you mean an RFC for rust and not c++ right?
  - klysm 5y ago
    From the syntax, yes
gsliepen 5y ago
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.

pie_flavor 5y ago

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.

johncolanduoni 5y ago
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.
- pjmlp 5y ago
  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 https://www.youtube.com/watch?v=E3JG2Ijjei4
- ATsch 5y ago
  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.
  - pjmlp 5y ago
    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).

jackosdev 5y ago

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

pjmlp 5y ago
C++23 is getting print if it goes according to plan.

gefhfffh 5y ago

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

megumax 5y ago
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?
- gefhfffh 5y ago
  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.
  - tialaramex 5y ago
    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.
    - gefhfffh 5y ago
      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
- kibwen 5y ago
  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).

deleted 5y ago

[deleted]

simias 5y ago

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

kibwen 5y ago

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.

accountofme 5y ago
just for clarity's sake: you mean an RFC for rust and not c++ right?
- klysm 5y ago
  From the syntax, yes

gsliepen 5y ago

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.