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

171–180 of 216 posts

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

#171

Post by mixmastamyk »

snthpy wrote: post #102
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. Sin…

I suppose simplicity and familiarity would be the primary two goals. Then congruence with SQL would be another factor specifically for PRQL.

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

#172

Post by TheRealPomax »

beeforpork wrote: post #104

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

The C++ language itself shouldn't be tied to any one specific application or third party tool, though. Just because they exist doesn't mean you are forced to use them, this is one of those cases where f strings don't make a lot of sense. Things with localized labels or text ideally have an id that gets looked up, so you can't do English-based string composition. Every locale gets looked up, no "just pass through the key if locale X", and lookup failures don't "still work", they result in super obvious, user-reportable nonsense.

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

#173

Post by eviks »

snthpy wrote: post #102
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. Sin…

some factors:

ease of typing: so regular quotes are better vs backticks (even with a prefix), F-prefix - better than $, requiring Shift

ease of learning: here letter-mnemonic seems easiest: so I-prefix for "interpolation" or E-prefix for "expression" or maybe V-prefix for "variable". Or maybe F for "formatted" is also fine?

familiarity: so F-prefix due to Python?

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

#174

Post by hnlmorg »

rat87 wrote: post #155
hnlmorg wrote: post #96

Earlier quoted context omitted.

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…

I think rust was helped by being part of Mozilla and really helped when they got experienced devs (guys who made ruby Bundler) to build the Cargo package manager pre 1.0 https://web.archive.org/web/20221206052719/https://mail.mozi... And helped a bit when they took a lot of stuff out the stdlib into packages for the new package manager. And helped a lot with a heavy focus pretty early on great compiler messages (insp…

> I think rust was helped by being part of Mozilla and really helped when they got experienced devs (guys who made ruby Bundler) to build the Cargo package manager pre 1.0

That's one of the reasons Rust became as widespread as it is now. However we are talking about a "what if Rust never existed" scenario. I'm confident that kind of scenario we'd be talking about a different-yet-similar language, maybe one that never got invented in our version of reality, as having the same or similar forces that helped that hypothetical language.

My point is that people wanted a successor to C++. So it was going to happen. In our reality it was Rust. But if Rust wasn't created by Greydon then someone else would have created something else to fill that void.

> I think it was far from inevitable that some other language to compete with c++ would have come out anytime soon if rust hadn't been around (and hadn't made good enough choices). It might have happened but decent chances it wouldn't have.

I very much disagree with this assumption. We have D, ObjectiveC, C#, Zig, Go, OCaml and others born out of the need to to iterate and improve on what came before it. But nothing had really caught on in the domain of safety + zero-cost abstractions principle. And particularly not aimed at C++ devs. It's been a contentious point for years -- a void people have been looking to fill. So it was only a matter of time before something caught on.

But this is all hypothetical. Plus if you subscribe to the many-worlds interpretation of quantum mechanics, then arguably we're both right :D

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

#175

Post by tempodox »

shultays wrote: post #166
tsimionescu wrote: post #122

Earlier quoted context omitted.

If a function takes a raw pointer, you need to check the docs to know if it is taking ownership or not. There is no general rule that applies to the whole of std that functions taking raw pointers assume that they are borrowing the value. And even if you could assume that pointer parameters represent borrowing, they are definitely not guaranteed to represent scoped borrowing: the function could store them somewhere,…

What are the examples to std functions that uses a raw pointer but does not borrow/expects pointer to be valid past the function call?

The fact that you have to ask that question makes GP's point. There's no way to tell that from looking at a function's interface at present.

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

#176

Post by shultays »

tempodox wrote: post #175
shultays wrote: post #166

Earlier quoted context omitted.

What are the examples to std functions that uses a raw pointer but does not borrow/expects pointer to be valid past the function call?

The fact that you have to ask that question makes GP's point. There's no way to tell that from looking at a function's interface at present.

Why? If all standard functions that take no ownership/keep references are using raw pointers then it behaves same as user code/C++ devs expect: if a function is taking a pointer then it claims no ownership. You take a look at standard_function(T*) and see raw pointer and then can assume it is not taking ownership or keeping references

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

#178

Post by groby_b »

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.

auto is fixing the problem of long-ass type names for intermediaries thanks to templates and iterators.

Move is fixing the problem of unnecessary mass-construction when you pass around containers.

std::ranges was introduced because dear fucking god the syntax for iterating over a partial container. (And the endless off-by-one errors)

concepts, among other things, fix (sorta) the utter shit show that templates brought to error messages, as well as debacles like SFINAE and std::enable_if.

You're right. They're not fixing problems created by previous features. They're all fixing problems created or made massively worse by templates.

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

#179

Post by Mond_ »

edflsafoiewq wrote: post #162
boxed wrote: post #145

Earlier quoted context omitted.

Three people in a row and not one of you guys checked out Swift strings before commenting, thus making exactly the mistake I complained about. Look up Swift strings. Python has 4 types of string literals. Swift has 1. And they are BETTER and more powerful. Cleaner.

Swift has "normal strings", #"raw strings"#, and """ for multiline strings. For interpolation, it uses "The answer is \(1+2)", but in a raw string you need #"The answer is \#(1+2)"#. So compared to Python, string interpolation is always "on" and doesn't need an f-prefix. Because it uses the string escaping syntax, it doesn't have to take over a regular character like {, which requires {{ escaping.

Is this supposed to be better than python? "Every string is an f-string, make sure you don't accidentally miss some interpolation." sounds like a step down, not like an improvement to me!

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

#180

Post by OskarS »

steveklabnik wrote: post #160
kringlezz wrote: post #132

Earlier quoted context omitted.

>There's no way the compiler can run that, because it doesn't know what x is (indeed, it would have a different value every time you run the function with a new argument). So your proposal would ditch const completely except in the constexpr case, everything runtime would have to be mutable. Yeah, I see no problem with that. Non-constant expressions usage of 'const' has always just seemed like a waste of time for me,…

> the main point was that "give me a constant value" should be at the usage site, not at the function definition. The issue is, not everything can be done at compile time, and so “I can use this at compile time” becomes part of the signature because you want to ensure that it will continue to be able to be used that way. Without it, changes in your function could easily break your callers.

Exactly right. There's a huge benefit to encode the ability for compile-time evaluation in the signature of the function itself. Much better than doing it "ad-hoc", like how template instantiation does it. Sometimes it will work, sometimes it doesn't. constexpr functions always work.
Post reply on HN