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

151–160 of 216 posts

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

#151

Post by neonsunset »

mkoubaa wrote: post #142
neonsunset wrote: post #129

Earlier quoted context omitted.

There is no need to just throw keywords around. For other readers - more than half of these are irrelevant. Writing general purpose application code rarely involves thinking about implications of most of these (save for NAOT as of lately I suppose). Writing systems C# involves additional learning curve, but if you are already familiar with C++, it comes down to understanding the correct mapping between features, lear…

The original comment was about the divergence of the complexity of a language and the complexity of programs implemented in the language. I think the comment you replied to with all its keywords and jargon beautifully illustrated the point

No one of sane mind accesses even one tenth of these on a daily basis.

They simply do not matter. For example - CLS-compatiblity, seriously? I'd return the favour and ask the interviewer why they disagree with the .NET's team stance that this lost relevance in early .NET versions more than a decade ago.

There are main framework and features to be aware of, there are some that may be relevant to legacy codebases you must avoid like fire, and there are those to which the only appropriate response would be "this never existed, if it did, forget about it".

(to Pjmlp - please do not equate knowing the terms with understanding them, and stop bringing up whatever was left by wayside of history to people who should have no business being bothered by this nonsense, thank you)

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

#152

Post by vitus »

bregma wrote: post #123
rerdavies wrote: post #80

Earlier quoted context omitted.

The safety and readability are nice; but WHY do they have to be in order? That is so typically clueless. Such an obvious feature, screwed up in a way that only a C++ committee member could.

Why does construction and destruction order need to be deterministic? Well, consider what would happen if you had members whose value depends on other members. For example, one member is a pointer to another. Or perhaps one member uses RAII to hold a lock and another controls a resource. Deterministic construction and destruction order is a fundamental feature of C++. Calling it clueless is just an indication one doe…

> Why does construction and destruction order need to be deterministic?

That question presupposes a particular compiler implementation of designated initializers. Indeed, C90 had the fixed-order requirement until C99 decided this was unnecessary and removed it.

> Well, consider what would happen if you had members whose value depends on other members.

Can you specify a designated initializer in that way, though? Either you specify a value, or you don't; I'm not aware of a way to introduce dependencies between members with a designated initializer. Yes, you can add a default initializer to a specific member, but that only kicks in if it's unspecified by the designated initializer.

With a constructor initializer list, sure, you can absolutely introduce dependencies on previously-constructed members. But that's not the case with a designated initializer.

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

#153

Post by Smar »

boxed wrote: post #144
VagabundoP wrote: post #92

Earlier quoted context omitted.

Most people really like python f-strings. You might be on your own here.

You missed half of what I said. Look at Swift. To quote myself: Yea, f-strings are nice. But f-strings, r-strings, \ escaping, {{ escaping, ''' strings? Horrible. Swift strings have ONE string. Just a single clean design that does all of that. With a simple set of rules.

I suppose Swift copied Ruby's strings, then.

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

#154

Post by boxed »

Smar wrote: post #153
boxed wrote: post #144

Earlier quoted context omitted.

You missed half of what I said. Look at Swift. To quote myself: Yea, f-strings are nice. But f-strings, r-strings, \ escaping, {{ escaping, ''' strings? Horrible. Swift strings have ONE string. Just a single clean design that does all of that. With a simple set of rules.

I suppose Swift copied Ruby's strings, then.

Looking at Ruby strings it seems not. They have at least two special syntaxes: escaping and interpolation. They seem to have some weird "Swift has just 1 string.

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

#155

Post by rat87 »

hnlmorg wrote: post #96
tialaramex wrote: post #82

Earlier quoted context omitted.

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…

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 (inspired by elm) and with a focus on tools and documentation more generally.

Like a lot of things in life, rust was in the right place at the right time to get popular. I do think the deep want for something better and safer then c++ helped but they made a lot of good choices(not necessarily the best choices but good enough choices) and had some money backing them. 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.

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

#156

Post by pjmlp »

neonsunset wrote: post #151
mkoubaa wrote: post #142

Earlier quoted context omitted.

The original comment was about the divergence of the complexity of a language and the complexity of programs implemented in the language. I think the comment you replied to with all its keywords and jargon beautifully illustrated the point

No one of sane mind accesses even one tenth of these on a daily basis. They simply do not matter. For example - CLS-compatiblity, seriously? I'd return the favour and ask the interviewer why they disagree with the .NET's team stance that this lost relevance in early .NET versions more than a decade ago. There are main framework and features to be aware of, there are some that may be relevant to legacy codebases you m…

Just like not everyone accesses 100% of C++ on daily basis on their work.

I do whatever I please, feel free to ignore my comments, downvote them, or whatever goes on your heart regarding them.

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

#157

Post by mikepurvis »

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?

Maybe it's not a concern in C-family languages, but rust's culture of defaulting to let and only using mut when it's specifically required does feel very pleasant and ergonomic when I'm in that headspace.

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

#158

Post by aiono »

tsimionescu wrote: post #98
aiono wrote: post #95

Earlier quoted context omitted.

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

Yes, it writes in the slide 6 of presentation that Bjarne himself created: https://github.com/CppCon/CppCon2023/blob/main/Presentations...

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

#159

Post by pklausler »

pjmlp wrote: post #49
mkoubaa wrote: post #3

Tangent: this sort of thing can be implemented without any change to libc++ (the runtime). Updates to compiler versions are sometimes postponed by users with big codebases that treat a libc++ change as something major. Why don't we see gcc or clang or msvc back porting stuff like this to an older version with a sort of future tag. It's normal to see __future__ in the python ecosystem, for instance.

Because C++, just like C, Ada, Cobol, Fortran, Modula-2, Pascal is an ISO driven language. Whereas Python language evolution is driven by whatever CPython reference implementation does. Compilers are free to do whatever they want, but then that code isn't portable.

> Compilers are free to do whatever they want, but then that code isn't portable.

At a practical level, this is no different from Fortran, “ISO driven” or not.

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

#160

Post by steveklabnik »

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

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

Post reply on HN