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

91–100 of 216 posts

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

#91

Post by OskarS »

fsloth wrote: post #41
edflsafoiewq wrote: post #32

Earlier quoted context omitted.

17 is worth it for std::filesystem alone. It also has optional and variant.

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…

> 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 “let’s pretend a while we are using some other language…” category.

I agree, they should have made it a language/syntax feature. However: if you wanna do a sum type, it does do that. I'd rather have that than nothing.

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

#93

Post by orf »

tialaramex wrote: post #22
edflsafoiewq wrote: post #17

Earlier quoted context omitted.

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

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

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

#94

Post by chlorion »

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.

Being able to use string formatting without a heap is pretty cool.

Rusts string formatting machinery does not require any heap allocations at all, you can for example impl fmt::Write for a struct that writes directly to a serial console byte-by-byte with no allocations, and then you have access to all of rusts string formatting features available to print over a serial console!

I'm not sure about the horrifying and dangerous extensions part though, I'm not really a C++ expert so I don't know if there's a better way to do what they want to do.

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

#95

Post by aiono »

jeroenhd wrote: post #85
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!

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

> the mess that causes the worst bugs is the result of a choice, not the language itself.

Even the creator of the language admitted that "just write better code bro" approach doesn't work.

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

#96

Post by hnlmorg »

tialaramex wrote: post #82
vanviegen wrote: post #68

Earlier quoted context omitted.

On the time scale of c++, rust is very recent. :-)

Nerd alt-history story: What if Graydon decides he should attend WG21 and so instead of Rust what we get is a decade of attempts to fix C++ and reform the process, followed by burn out?

Then we'd be supporting a different language that shares the same or similar ideals as Rust. Whether that's something already in existence or something entirely new.

Rust isn't really that unique, there are plenty of other safe languages out there. And if Graydon was alone in wanting something like Rust then Rust wouldn't have grown in popularity like it has.

Rust exists because enough people thought there was a need for Rust to exist. So if that wasn't Graydon with Rust, then it would have been someone else with something else.

This isn't meant to take anything away from Graydon nor Rust. Just saying that innovations seldom happen in silos. They're usually a result of teams of people lusting for change.

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

#97

Post by tsimionescu »

jeroenhd wrote: post #85
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!

> 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.

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

#98

Post by tsimionescu »

aiono wrote: post #95
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…

> the mess that causes the worst bugs is the result of a choice, not the language itself. Even the creator of the language admitted that "just write better code bro" approach doesn't work.

Has he? He at least used to be the biggest proponent of it, "just follow these standards and development practices that I had to meticulously develop for the US military, that no tool can automatically check, and you'll be fine!".

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

#99

Post by orf »

ggm wrote: post #34

I'm going to make an asinine prediction. We will be exploring F-strings in future languages in 100 years time, encountering the same problems and questions. I still use printf semantics in Python3 despite trying to get with the program for symbolic string/template logic. I don't need to be told it's better, I need some Philip-K-Dick level brain re-wiring not to reach for "%d things I hate about f-strings\n" % (int(ma…

FYI that code sample is broken, it should be `(int(many()),)`

Ironic I guess?

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

#100

Post by debugnik »

pshirshov wrote: post #71
neonsunset wrote: post #29

Reinventing C#’s FormattableString and interpolated string handlers :)

C# wasn't the first language which introduced such mechanism.

But they got the type decay right without introducing further user-defined conversions, unlike this proposal. The syntax is ad hoc, thus so should be the typing rule.
Post reply on HN