Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

open-std.org

Post reply on HN
Print view View original

21–30 of 216 posts

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

#21

Post by wakawaka28 »

edflsafoiewq wrote: post #15
puffybuf wrote: post #9

Earlier quoted context omitted.

how would this work with internationalized strings? especially if you have to change the order of things? You'd still need a string version with object ordering I would think

f-strings are not an internationalization library.

The question was, how would you use this if you have i18n requirements. Format strings are normally part of a translation. I think the bad answer is to embed the entire f-string for a translation as usual, except this can't work because C++ f-strings would need to be compiled. The better answer is, don't use f-strings for this because you don't want translators to monkey around with code and you don't want to compile 50 versions of your code.

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

#22

Post by tialaramex »

edflsafoiewq wrote: post #17
amluto wrote: post #12

This links to a “decays_to” proposal: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p33... And observes that this additional feature is needed to avoid dangling references. And, as a long time C++ programmer, this illustrates one of the things I dislike most about C++. In most languages, if you make a little mistake involving mixing up something that references something else with something that contains a…

IOW I believe it's the same thing as Rust's format_args! macro, but trying to get away without needing a separate format! macro by using implicit conversions.

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 the answer is a compile time fixed string anyway and give you that string, but it might not even if you think it should and no promises are given.

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

#23

Post by efitz »

When I saw the title I thought “F-strings” might be some novel variant of P—strings. I was disappointed that this is just about formatting. I really would prefer safer string handling in modern C/++

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

#24

Post by amluto »

thaumasiotes wrote: post #20
amluto wrote: post #12

This links to a “decays_to” proposal: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p33... And observes that this additional feature is needed to avoid dangling references. And, as a long time C++ programmer, this illustrates one of the things I dislike most about C++. In most languages, if you make a little mistake involving mixing up something that references something else with something that contains a…

> But, of course, more advanced users might know what they’re doing and want to bypass this hack, so: explicit auto s = f"{foo}"; > Does what they programmer actually typed, so s captures foo by reference. Wouldn't this problem be best solved by... not declaring s to have a guess-what-I-mean type? If you want to be explicit about the type of s, why not just say what that type is? Wouldn't that be even more explicit t…

A general issue with C++ (and many statically typed languages with generic) is hilariously long type names that may even be implementation details. Using auto can be a huge time saver and even necessary for some generic code. And people get in the habit of using it.

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

#25

Post by andyg_blog »

I agree that we should have safe-by-default "decay" behavior to a plain ol std::string, but I'm also picking up that many aren't certain it's a useful syntactic sugar in top of the fmt lib? Many other languages have this same syntax and it quickly becomes your go-to way to concatenate variables into a string. Even if it didn't handle utf-8 out of the box, so what? The amount of utility is still worth it.

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

#26

Post by mixmastamyk »

So, the f-string in Python is "spelled" that way because another leading character was the only ASCII syntax left for such a thing. It's odd that PRQL and now potentially C++ might copy it. In the PRQL case it was a new thing so they could have chosen anything, double quotes (like shell interpolation) or even backticks, that seem to make more sense.

Also the f- prefix was supposed to be short for format and pronounced that way. But "eff" caught on and now devs the world over are calling them "eff strings" ... funny. :-D

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

#27

Post by ryandrake »

dgfitz wrote: post #19

Somehow I manage to get by just fine with c++11. I have refactored more than a few codebases that use 17 or greater. Strangely, the codebase became more maintainable afterwards.

Came here to post the same thing. C++11 was a major and practical step up from previous versions. I haven't seen anything in future standards that looked like it a tool I'd use day-to-day building actual production software. Much of the subsequent versions added things probably interesting to compiler and language academics. "Default constructible and assignable stateless lambdas?" Really?

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

#28

Post by hackyhacky »

mkoubaa wrote: post #4
puffybuf wrote: post #2

I'm pretty sure boost::format can do this, though not inline in the string. Do we really need more complexity in cpp? isn't it complex enough?

This is the sort of change that adds complexity to the language but reduces complexity in the code written in the language. We take those

> This is the sort of change that adds complexity to the language but reduces complexity in the code written in the language. We take those

An admirable statement of policy, but I'm not sure it's possible. Adding complexity to the language means there are more gotchas and edge-cases that a programmer must consider, even if they don't use the feature in question.

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

#30

Post by vitus »

ryandrake wrote: post #27
dgfitz wrote: post #19

Somehow I manage to get by just fine with c++11. I have refactored more than a few codebases that use 17 or greater. Strangely, the codebase became more maintainable afterwards.

Came here to post the same thing. C++11 was a major and practical step up from previous versions. I haven't seen anything in future standards that looked like it a tool I'd use day-to-day building actual production software. Much of the subsequent versions added things probably interesting to compiler and language academics. "Default constructible and assignable stateless lambdas?" Really?

Off the top of my head, C++17 brought slicker notation for nested namespaces, digit separators for numeric literals (so you can more easily read 1'000'000'000), improvements in type deduction for pairs / tuples (so std::make_pair / make_tuple are basically unnecessary now), guarantees in the standard for copy elision / return value optimization in specific circumstances,. Oh, and structured bindings (so you can now write `for (const auto& [key, value] : map) { ... }`).

edit: I guess digit separators came in C++14, I'm always a little fuzzy there since at work, we jumped straight from 11 -> 17.

C++20 brought a feature that C had decades prior: designated initializers, except it's in a slightly crappier form. Also, spaceship operator (three-way comparison).

Looking at cppreference, it looks like C++17 also brought if constexpr, and standardized a bunch of nonstandard compiler extensions like [[fallthrough]]. C++20 continued standardizing more of those extensions, and also brought concepts / constraints, which are a lot easier to use than template metaprogramming.

You're at least somewhat right though -- none of these are paradigm shifts as C++11 was compared to C++03 (especially with the notion of ownership, especially in the context of std::unique_ptr and std::move).

Post reply on HN