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

161–170 of 216 posts

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

#161

Post by gpderetta »

nurettin wrote: post #137
gpderetta wrote: post #108

Earlier quoted context omitted.

Iteratively improving in previously released features does not imply fixing issues caused by those features. Constexpr and auto have nothing to do with macros.

To me, redoing things that are not orthogonal implies that the older version is being fixed. Being fixed implies that it was incorrect. And to clarify, sure, auto types and constexpr are entirely new things we didn't have (auto changed meaning but yeah), but we were trying to "get something like that" using macros.

> To me, redoing things that are not orthogonal implies that the older version is being fixed

The older version is being improved, especially for ergonomics. Regarding your examples, ranges do not obsolete iterators, they are just a convenient way to pass around iterator pairs, but actual range are better implemented in terms of iterators when they are not just a composition of ranges. Similarly move semantics has little to do with nrvo (and in fact using move often is suboptimal as it inhibits nrvo).

Again, I have no idea how constexpr and auto have anything to do with macros.

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

#162

Post by edflsafoiewq »

boxed wrote: post #145
hikarudo wrote: post #88

Earlier quoted context omitted.

Sincere question: what's wrong with Python f-strings?

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.

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

#163

Post by UncleMeat »

kringlezz wrote: post #132
OskarS wrote: post #128

Earlier quoted context omitted.

I agree that I would have preferred destructive moves, but move semantics makes C++ a much richer and better language. I kinda think pre-move semantics, C++ didn't quite make "sense" as a systems programming language. Move semantics really tied the room together. const int x = f(); // this is always get evaluated at compile time, (or if it can't, then fail to compile) That's very silly. You're saying this should fail…

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

I like const because I can look at a function signature and know that nothing downstream is mutating a parameter. I can also write a function that returns a const reference to a member and know that nobody in the future will ever break my invariants.

This isn't about "oops, I didn't mean to mutate that." This is about rapidly being able to reason about the correctness of some code that is leveraging const-qualified code.

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

#164

Post by jcelerier »

kringlezz wrote: post #132
OskarS wrote: post #128

Earlier quoted context omitted.

I agree that I would have preferred destructive moves, but move semantics makes C++ a much richer and better language. I kinda think pre-move semantics, C++ didn't quite make "sense" as a systems programming language. Move semantics really tied the room together. const int x = f(); // this is always get evaluated at compile time, (or if it can't, then fail to compile) That's very silly. You're saying this should fail…

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

> (when has that ever happened?)

to me, pretty much a few times per week at least

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

#165

Post by amluto »

vitus wrote: post #150
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,…

> "preventing themselves from accidentally mutating a variable" (when has that ever happened?) I can't count the number of times I've seen someone new to the language use map::operator[] without realizing that it's a mutating operation.

It’s extra delightful that vector::operator[] isn’t mutating, so you can change a vector to a map and get rather different semantics.

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

#166

Post by shultays »

tsimionescu wrote: post #122
a_t48 wrote: post #107

Earlier quoted context omitted.

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

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?

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

#167

Post by amluto »

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…

Do these “modern C++ safety features” actually exist in any usable manner?

string_view, for example, is very modern and is utterly and completely unsafe.

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

#168

Post by mixmastamyk »

lifthrasiir wrote: post #120
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…

> [...] another leading character was the only ASCII syntax left for such a thing. Not really? The original PEP [1] for example considered `i"asdf"` as an alternative syntax. Any ASCII Latin letter besides from `b`, `r` and `u` would have been usable. [1] https://peps.python.org/pep-0498/#how-to-denote-f-strings

As an alternative to another leading ascii character, you offer another leading ascii character?

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

#169

Post by TheRealPomax »

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.

It might be getting tiresome because it keeps being true, so people keep pointing it out.

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

#170

Post by mixmastamyk »

eviks wrote: post #90
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…

Why is it odd to copy a popular and fitting alternative? What's the better one?

Because it’s an variant with a wart, only picked from being backed into a corner. I mentioned shell interpolation in my previous comment.
Post reply on HN