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

211–216 of 216 posts

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

#211

Post by gpderetta »

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…

There are many cases in C++ where the type is unspecified (std::bind for example), or even is unutterable (lambdas, or unnamed structures). I think F-strings would be an example of the latter.

You can always box of course (std::function, std::any at the limit), but it has a non-trivial cost.

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

#212

Post by gpderetta »

derriz wrote: post #77
qalmakka wrote: post #46

Earlier quoted context omitted.

C++20's concepts IMHO are a massive update over C++11. You can basically remove almost 90% of inheritance with them without incurring in any issue (you could do that earlier too, but at the expense of incredibly hard to read error messages - now that's basically solved thanks to concepts).

I don't find the error messages produced by concepts much better than old school template errors. Maybe I got used to the latter with experience and definitely the compilers got better at generating useful error messages for templates as the years passed. On the other hand when I have to review code where a significant portion of the source relates to concepts, my heart sinks. In my opinion, C++ "concepts" are the le…

>[...] "concept" must be the least descriptive, least useful. Why pick such a meaningless name

That's the name that Stepanov used 30 years ago to describe the informal type constraints of templates and has been in use in the community since them. Choosing anything else for the language feature would not make sense.

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

#213

Post by gpderetta »

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.

For example, an high performance logger can ship the tuple object to a background thread for actual formatting and I/O, after converting the capture to by-value.

Formatting on the foreground thread would be a non-starter.

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

#214

Post by bicarbonato »

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.

> How are concepts fixing a problem created by previous features to the langue?

Concepts fix implicit template requirements

> What about ranges?

Fix the bad iterators

> Auto

Fix the the overly long type names

> Move semantics

This is mostly necessary because of excessive copies that cpp does

> Consteval

Fix cases where constexpr couldn't do it at comptime

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

#215

Post by cemdervis »

pjmlp wrote: post #52
fsloth wrote: post #41

Earlier quoted context omitted.

Filesystem is great. It’s insane it took so long. Optional is nice but slightly awkward in a non-garbage collected language. IMO variant is one of those things that should not exist in standard. It tries to implement discriminated union in C++ but that feature is lame without true pattern matching. And you can’t implement pattern matching without thorough syntax level support. So in my books it’s in this academic “le…

Might still land on C++26, but most likely C++29, then you'll have pattern matching.

Fingers crossed
Post reply on HN