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

141–150 of 216 posts

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

#141

Post by lifthrasiir »

orf wrote: post #138
lifthrasiir wrote: post #119

Earlier quoted context omitted.

It is not a shortcut because it can't be implemented without knowing the `Arguments` internals. `format_args!("{}", "boo").as_str()` returns None for example.

It’s a shortcut in the sense that most, if not all optimisations are shortcuts. This one allows you to shortcut the usual formatting machinery if the result of formatting is a static string. Like all shortcuts, it’s not something you can always rely on.

It can be used to shortcut the formatting process, the function itself is however not a shortcut in my opinion.

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

#142

Post by mkoubaa »

neonsunset wrote: post #129
pjmlp wrote: post #114

Earlier quoted context omitted.

C# has already enough material for pub Quiz, and no, not all of them are syntatic sugar, and require deep knowledge of the .NET runtime, and the way it interacts with the host platforms. I imagine you never went too deep into unsafe, cross language interop, lambda evolution since the delegate days, events infrastructure, pluggable GC, RCW/CCW, JIT monitoring, the new COM replacement, how the runtime and language feat…

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

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

#143

Post by boxed »

mort96 wrote: post #106
boxed wrote: post #78

Jesus. This is such a bad idea. Don't repeat the mistakes of Python. Look at what Swift does and make a SANE system ffs.

F-strings is one of my favorite features of Python to be honest. That doesn't automatically mean it's a good idea in C++, knowing C++ there are gonna be a whole lot of gotchas which aren't in Python, but it means that, at least in my opinion, how F-strings worked in Python is an argument in favor of them rather than against them.

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.

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

#144

Post by boxed »

VagabundoP wrote: post #92
boxed wrote: post #78

Jesus. This is such a bad idea. Don't repeat the mistakes of Python. Look at what Swift does and make a SANE system ffs.

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.

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

#145

Post by boxed »

hikarudo wrote: post #88
boxed wrote: post #78

Jesus. This is such a bad idea. Don't repeat the mistakes of Python. Look at what Swift does and make a SANE system ffs.

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.

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

#146

Post by wakawaka28 »

mkoubaa wrote: post #140
wakawaka28 wrote: post #21

Earlier quoted context omitted.

The question was, how would you use this if you have i18n requirements. Format strings are normally part of a translation. I think the bad answer is to embed the entire f-string for a translation as usual, except this can't work because C++ f-strings would need to be compiled. The better answer is, don't use f-strings for this because you don't want translators to monkey around with code and you don't want to compile…

C++ is such a narrow skillset that I'd rather not roll the dice on translators knowing what to do

Even if you told them, "just copy the names from the original string" it's still asking for trouble, and maybe even security holes if they don't follow instructions. But the biggest problem with the idea is surely that the strings need to be compiled.

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

#147

Post by pjmlp »

lifthrasiir wrote: post #118
pjmlp wrote: post #115

Earlier quoted context omitted.

First we need to rewrite the likes of LLVM, GCC, V8, CUDA,... into something else. Which is not going to happen in our lifetime, even the mighty Rust depends on LLVM for its reference implementation.

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.

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

#148

Post by pjmlp »

neonsunset wrote: post #129
pjmlp wrote: post #114

Earlier quoted context omitted.

C# has already enough material for pub Quiz, and no, not all of them are syntatic sugar, and require deep knowledge of the .NET runtime, and the way it interacts with the host platforms. I imagine you never went too deep into unsafe, cross language interop, lambda evolution since the delegate days, events infrastructure, pluggable GC, RCW/CCW, JIT monitoring, the new COM replacement, how the runtime and language feat…

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…

Many of those keywords as you call it, are part of a technical interview in any .NET consulting shop worth their business.

And while I expect any junior not to know half of them, anyone claiming to be a senior better have an answer, regardless of what I throw at them.

Naturally I don't expect anyone versed in desktop frameworks to master backend and vice-versa, but they better know the bits that relate to desktop in that case, across the whole stack.

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

#149

Post by orf »

lifthrasiir wrote: post #141
orf wrote: post #138

Earlier quoted context omitted.

It’s a shortcut in the sense that most, if not all optimisations are shortcuts. This one allows you to shortcut the usual formatting machinery if the result of formatting is a static string. Like all shortcuts, it’s not something you can always rely on.

It can be used to shortcut the formatting process, the function itself is however not a shortcut in my opinion.

Interesting viewpoint: I see this as a distinction without a difference. I’m interested to know why you see it differently? What is its use, if not as a shortcut?

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

#150

Post by vitus »

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

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

Post reply on HN