F-strings for C++26 proposal [pdf]

Post by ajb » Mon, Feb 03, 2025, 10:06 AM UTC

jeroenhd wrote: post #86

ajb wrote: post #63

Earlier quoted context omitted.

Hah. What's interesting about this is that since it doesn't require everything to actually be converted to a string, one can implement things other than just printing. So you could also implement interpretation, eg: pylist = python(f"[ y*{coef} for y in {pylist} if y > {threshold}]")

It also allow for things that will set off spidey senses in programmers everywhere despite theoretically being completely safe assuming mydb::sql() handles escaping in the format string: cursor = mydb::sql(f"UPDATE user SET password={password} WHERE user.id={userid}")

Post by f1shy » Mon, Feb 03, 2025, 10:44 AM UTC

nialv7 wrote: post #75

edflsafoiewq wrote: post #11

So the f-string literal produces a basic_formatted_string, which is basically a reified argument list for std::format, instead of a basic_string. This allows eg. println to be overloaded to operate on basic_formatted_string without allocating an intermediate string std::println("Center is: {}", getCenter()); std::println(f"Center is: {getCenter()}"); // same thing, no basic_string allocated In exchange we have the fo…

One of the two other proposals is user defined type decay, which lets you choose what type auto will be deduced as. i.e. "auto x = y", x might not have the type of y, instead it can be anything you choose… This is like implicit type conversion on steroids. And all this because C++ lacks the basic safety features to avoid dangling pointers. Stop using C++ already!

Post by pjmlp » Mon, Feb 03, 2025, 10:59 AM UTC

nialv7 wrote: post #75

edflsafoiewq wrote: post #11

So the f-string literal produces a basic_formatted_string, which is basically a reified argument list for std::format, instead of a basic_string. This allows eg. println to be overloaded to operate on basic_formatted_string without allocating an intermediate string std::println("Center is: {}", getCenter()); std::println(f"Center is: {getCenter()}"); // same thing, no basic_string allocated In exchange we have the fo…

One of the two other proposals is user defined type decay, which lets you choose what type auto will be deduced as. i.e. "auto x = y", x might not have the type of y, instead it can be anything you choose… This is like implicit type conversion on steroids. And all this because C++ lacks the basic safety features to avoid dangling pointers. Stop using C++ already!

Post by kringlezz » Mon, Feb 03, 2025, 11:16 AM UTC

blux wrote: post #74

serbuvlad wrote: post #64

Earlier quoted context omitted.

> There are two other proposals to fix these problems. Most new features of C++ are introduced to fix problems created by previously new features added to C++.

This is becoming such a tiresome opinion. How are concepts fixing a problem created by previous features to the langue? What about ranges? Auto? Move semantics? Coroutines? Constexpr? Consteval? It is time for this narrative to stop.

  int f() { ... } // any old regular function
  const int x = f(); // this is always get evaluated at compile time, (or if it can't, then fail to compile)
  int y = f(); // this is evaulated at runtime

Post by lifthrasiir » Mon, Feb 03, 2025, 11:28 AM UTC

orf wrote: post #93

tialaramex wrote: post #22

Earlier quoted context omitted.

std::format_args! gets you a Arguments which we'll note means it has an associated lifetime. Today-I-learned, Arguments has a single useful function, which appeared before I learned Rust but only very recently became usable in compile time constants, as_str() -> Option format_args!("Boo!").as_str() is Some("Boo!") If you format a literal, this always works, if you format some non-literal the compiler might realise th…

The most useful function is Arguments::fmt. “as_str” is just a shortcut utility function.