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

181–190 of 216 posts

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

#181

Post by edflsafoiewq »

Mond_ wrote: post #179
edflsafoiewq wrote: post #162

Earlier quoted context omitted.

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!

What do you mean by "miss some interpolation"?

There are two errors you could make in Python. Accidentally using {} in a normal string where you wanted interpolation, and accidentally using {} in an f-string where you wanted literal {}. I definitely do the former a lot.

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

#182

Post by justinrubek »

pjmlp wrote: post #147
lifthrasiir wrote: post #118

Earlier quoted context omitted.

Stop producing a new C++ code as much as possible, then. It doesn't help to nitpick the weakest possible interpretation without acknowledging as such.

Which by definition means no more improvements to LLVM then, as one example, and by consequence no improvements on Rust backend.

"as much as possible" nobody said anything about entirely stopping.

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

#183

Post by usefulcat »

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.

shared_ptr and unique_ptr aren’t useful for reasoning about the lifetimes of stack-based objects (unless you’re willing to require that such objects always be dynamically allocated, which is often not a reasonable requirement).

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

#184

Post by boxed »

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.

Close. But wrong.

Swift doesn't have raw strings and normal strings. Swift has ONE syntax:

{#n}"string {#n}\(interpolation)"{#*n}

Where n can be zero or more. So let's recap:

1. ONE rule for start/end/escape prefix: A number of # that has to match. 2. ONE rule for escape: \.

I do Python full time and I wouldn't consider switching to Swift, but the string situation is horrible compared to Swift.

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

#185

Post by boxed »

Mond_ wrote: post #179
edflsafoiewq wrote: post #162

Earlier quoted context omitted.

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!

The escape character is \. Same as in Python. But in Python you have to watch out for \ AND {. In Swift, only \.

And you can do this:

####"foo ###\(this is not interpolation) ####\(but this is) bar"####

In Pythons f-strings you can't ever write the literal `{foo}` in a string for documentation for example. It's a mess.

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

#186

Post by verall »

pjmlp wrote: post #51
verall wrote: post #43

Earlier quoted context omitted.

> 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. Since this is C++, this is not a problem we have to consider

This is a meme by now, yet it isn't as if Python 3.13 is a simple as Python 1.0, Java 23 versus Java 1.0, .NET 9 with C# 13 versus .NET 1.0 with C# 1.0 and a Framework reboot,....

Yes of course, and I mean it somewhat seriously - C++ engineers are used to the language being too complex for anyone to completely understand. It's worth some more incremental language complexity to support niceties like fstrings without additional overhead.

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

#187

Post by edflsafoiewq »

boxed wrote: post #184
edflsafoiewq wrote: post #162

Earlier quoted context omitted.

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.

Close. But wrong. Swift doesn't have raw strings and normal strings. Swift has ONE syntax: {# n}"string {# n}\(interpolation)"{#*n} Where n can be zero or more. So let's recap: 1. ONE rule for start/end/escape prefix: A number of # that has to match. 2. ONE rule for escape: \. I do Python full time and I wouldn't consider switching to Swift, but the string situation is horrible compared to Swift.

Yes it does, because normal strings aren't just a special case of raw strings when the number of #s is 0. The presence of #s change the string syntax. Otherwise you could as well say Python has one syntax, with optional f and r prefixes.

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

#188

Post by tialaramex »

orf wrote: post #93
tialaramex wrote: post #22

Earlier quoted context omitted.

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.

But there is no Arguments::fmt ? Are you thinking of the implementations of Debug::fmt and Display::fmt on Arguments ? Trait implementation isn't the same kind of thing at all.

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

#189

Post by orf »

tialaramex wrote: post #188
orf wrote: post #93

Earlier quoted context omitted.

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

But there is no Arguments::fmt ? Are you thinking of the implementations of Debug::fmt and Display::fmt on Arguments ? Trait implementation isn't the same kind of thing at all.

There is exactly one useful thing you can do with an `Arguments` object: call `.fmt()` on it.

The whole reason for std::Arguments very existence is to call `std::Arguments::fmt` on it.

`.fmt()` is a trait implementation, but that doesn’t change anything (not sure what “kind of thing” refers to here). It’s still a function on std::Arguments.

Post reply on HN