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

41–50 of 216 posts

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

#41

Post by fsloth »

edflsafoiewq wrote: post #32
vitus wrote: post #30

Earlier quoted context omitted.

Off the top of my head, C++17 brought slicker notation for nested namespaces, digit separators for numeric literals (so you can more easily read 1'000'000'000), improvements in type deduction for pairs / tuples (so std::make_pair / make_tuple are basically unnecessary now), guarantees in the standard for copy elision / return value optimization in specific circumstances,. Oh, and structured bindings (so you can now w…

17 is worth it for std::filesystem alone. It also has optional and variant.

Filesystem is great. It’s insane it took so long.

Optional is nice but slightly awkward in a non-garbage collected language.

IMO variant is one of those things that should not exist in standard.

It tries to implement discriminated union in C++ but that feature is lame without true pattern matching. And you can’t implement pattern matching without thorough syntax level support. So in my books it’s in this academic “let’s pretend a while we are using some other language…” category.

It’s _occassionally_ convenient for sure.

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

#43

Post by verall »

hackyhacky wrote: post #28
mkoubaa wrote: post #4

Earlier quoted context omitted.

This is the sort of change that adds complexity to the language but reduces complexity in the code written in the language. We take those

> This is the sort of change that adds complexity to the language but reduces complexity in the code written in the language. We take those An admirable statement of policy, but I'm not sure it's possible. 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.

> 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

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

#44

Post by truncate »

hackyhacky wrote: post #28
mkoubaa wrote: post #4

Earlier quoted context omitted.

This is the sort of change that adds complexity to the language but reduces complexity in the code written in the language. We take those

> This is the sort of change that adds complexity to the language but reduces complexity in the code written in the language. We take those An admirable statement of policy, but I'm not sure it's possible. 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.

Depends on case to case basis. I wouldn't generalize it to every case. As a daily C++ engineer, I think overall many features added over the years have mostly been positive. There are features that I don't use and I don't think it really affects much. That said, I do get the sentiment of language becoming too syntactically complex.

I like this feature as string formatting is something frequently used and this certainly looks cleaner and quicker to write.

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

#46

Post by qalmakka »

dgfitz wrote: post #19

Somehow I manage to get by just fine with c++11. I have refactored more than a few codebases that use 17 or greater. Strangely, the codebase became more maintainable afterwards.

C++20's concepts IMHO are a massive update over C++11. You can basically remove almost 90% of inheritance with them without incurring in any issue (you could do that earlier too, but at the expense of incredibly hard to read error messages - now that's basically solved thanks to concepts).

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

#47

Post by qalmakka »

alterom wrote: post #37

Yeah, I really missed ubiquitous C preprocessor macros in C++, so let's bring them back, but now inside string literals. Sweet. Seriously, I just keep being amazed that people are running with the idea of having a full-blown untyped and unchecked formatting mini language (that's what libfmt, which became C++20 format, literally calls it) inside string literals — i.e., the part of the source code that you're specifica…

So basically doing the same at runtime for the last 55 years was somewhat OK?

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

#49

Post by pjmlp »

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.

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

#50

Post by pjmlp »

feverzsj wrote: post #45

Like the compile time isn't long enough. They should just let the compiler do the job like Wformat=2 and skip any preprocess and constexpr function.

It is fast enough when using precompiled headers, binary libraries, and best of all C++20 modules with C++23 modularised standard library.

Could it be better? Most likely.

Post reply on HN