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

101–110 of 216 posts

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

#101

Post by tsimionescu »

thegrim33 wrote: post #79
nialv7 wrote: post #75

Earlier quoted context omitted.

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!

Smart pointers were added to the language 14 years ago. You're free to use old C++ with raw pointers and manual memory management, risking dangling pointers, or use modern C++, which provides smart pointers to avoid those issues.

And yet most if not all of the standard library keeps using pointer or reference arguments, not the new smart pointers that would actually document the ownership semantics.

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

#102

Post by snthpy »

mixmastamyk wrote: post #26

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 pronounce…

PRQL contributor here:

That is a valid point and something I've also been thinking about lately. I can't speak for the others but in my case the Python string interpolation syntax was the one I was most familiar with, other than bash, so it was just the default. The big idea really is to have string interpolation and the syntax is somewhat secondary but we do aim for ergonomics with PRQL so it is a consideration.

Since then I've seen more alternatives like `Hello ${var}!` in JS/TS and $"Hello {var}!" in F#. Not sure that there's a clear way to prefer one approach over the others.

What would you consider to be factors that would make you prefer one over the others?

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

#103

Post by nurettin »

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.

I thought the whole point of ranges is to solve problems created by iterators, move semantics to take care of scenarios where nrvo doesn't apply, constexpr and auto because we were hacking around it with macros (if you can even call it that)?

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

#104

Post by beeforpork »

It would be nice to take care to allow the use of GNU gettext() or any other convenient translation tool.

Recap: _("foo %s") macroexpands to gettext("foo %s"), then "foo %s" is extracted to a lexicon of strings by an external tool, which can be translated and compiled into .po files, which are loaded at runtime so gettext() can use a translated string based on $LC_MESSAGES. (And there is also _N(..) for correct plural handling.)

To do this with f-strings, _(f"foo {name()}") (which is a bit ugly...) needs to translate to make_formatted_string(_("foo {}"), name()) -- note that the _(...) needs to be called before calling make_formatted_string, to be able to return a translated string.

I would wish for a proposal for f-strings to consider translating strings, because we live in a world with many languages. And maybe cite gettext as a convenient method, and think about what could be done. Or point to a better tool. Or state: 'in that case, f-strings cannot be used'.

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

#105

Post by saagarjha »

tsimionescu wrote: post #97
jeroenhd wrote: post #85

Earlier quoted context omitted.

> lacks the basic safety features to avoid dangling pointers It doesn't. Unfortunately, C++ programmers choose not to use basic safety features for performance reasons (or aesthetics, or disagreement with the idea that a language should take into account that a programmer might make a mistake, but at least performance is a good one), but C++ actually has quite a few tricks to prevent the memory management issues that…

Tell that to the designers of the C++ standard library, and the new features being added. They're the ones that keep adding new features that depend on references and pointers instead of std::shared_ptr or std::unique_ptr.

I think one problem here is that a lot of codebases have their own smart pointers and unfortunately the only currency type is the unsafe one :(

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

#106

Post by mort96 »

boxed wrote: post #78

Jesus. This is such a bad idea. Don't repeat the mistakes of Python. Look at what Swift does and make a SANE system ffs.

F-strings is one of my favorite features of Python to be honest.

That doesn't automatically mean it's a good idea in C++, knowing C++ there are gonna be a whole lot of gotchas which aren't in Python, but it means that, at least in my opinion, how F-strings worked in Python is an argument in favor of them rather than against them.

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

#107

Post by a_t48 »

tsimionescu wrote: post #101
thegrim33 wrote: post #79

Earlier quoted context omitted.

Smart pointers were added to the language 14 years ago. You're free to use old C++ with raw pointers and manual memory management, risking dangling pointers, or use modern C++, which provides smart pointers to avoid those issues.

And yet most if not all of the standard library keeps using pointer or reference arguments, not the new smart pointers that would actually document the ownership semantics.

Most arguments to standard library calls don't need to take ownership over memory, using a raw pointer or (const) reference is correct. Generally - smart pointers to designate ownership, raw pointers to "borrow".

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

#108

Post by gpderetta »

nurettin wrote: post #103
blux wrote: post #74

Earlier quoted context omitted.

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.

I thought the whole point of ranges is to solve problems created by iterators, move semantics to take care of scenarios where nrvo doesn't apply, constexpr and auto because we were hacking around it with macros (if you can even call it that)?

Iteratively improving in previously released features does not imply fixing issues caused by those features.

Constexpr and auto have nothing to do with macros.

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

#109

Post by badmintonbaseba »

rerdavies wrote: post #87
HeliumHydride wrote: post #5

Earlier quoted context omitted.

C++ also has std::format, which was introduced in C++20. This is just sugar on top of it, except it also returns a container type so that printing functions can have overloads that format into a file or stream directly from an f-string, instead of going through the overhead of a temporary string.

I'm wonder what this mysterious application is that is doing heavy formatting of strings but can't afford the overhead of a temporary string, and therefore requires horrifying and inscrutable and dangerous language extensions.

freestanding maybe? Embedded apps often don't shy away from using something like printf, yet they don't like unnecessary allocations.

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

#110

Post by a_t48 »

rerdavies wrote: post #80
darknavi wrote: post #38

Earlier quoted context omitted.

Designated initializers are so nice. Even though they have C++-isms like required order, it adds safety and readability to code.

The safety and readability are nice; but WHY do they have to be in order? That is so typically clueless. Such an obvious feature, screwed up in a way that only a C++ committee member could.

Initializers for members are _always_ run in the order the member is declared - this applies even in constructor initializing lists, see https://en.cppreference.com/w/cpp/language/constructor#:~:te... - it doesn't matter what order you declare the initializers in, and clang will warn you if you write your initializers in an order other than what they will be executed in. Designated initializers are the same way, it's probably best that the behavior is consistent across methods of constructing.

Why is it this way? As best as I can find it's so that destructors always run in reverse order of construction, I guess there could be some edge cases there that matter. It's not the strongest argument, but it's not nothing.

Post reply on HN