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

51–60 of 216 posts

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

#51

Post by pjmlp »

verall wrote: post #43
hackyhacky wrote: post #28

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

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

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

#52

Post by pjmlp »

fsloth wrote: post #41
edflsafoiewq wrote: post #32

Earlier quoted context omitted.

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 “le…

Might still land on C++26, but most likely C++29, then you'll have pattern matching.

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

#53

Post by forrestthewoods »

pjmlp wrote: post #50
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.

C++ modules do not exist in practice and probably never will.

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

#54

Post by grandempire »

pjmlp wrote: post #50
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.

> best of all C++20 modules

Do any compilers besides VS support this?

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

#55

Post by pjmlp »

boguscoder wrote: post #42
_zagj wrote: post #36

Earlier quoted context omitted.

constexpr "if" statements (C++20) are also a game-changer.

Those are c++17

Initially, C++20 and C++23 extended its use cases, and combined with concepts is a pretty sweet spot for compile time metaprogramming without SFINAE or tag dispatch tricks.

Much better than having yet another syntax for macros.

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

#56

Post by pjmlp »

grandempire wrote: post #54
pjmlp wrote: post #50

Earlier quoted context omitted.

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.

> best of all C++20 modules Do any compilers besides VS support this?

Clang with CMake and ninja as build system (cmake.js for nodejs does as well).

The only missing piece is that cmake is still in the process to support header units.

GCC is getting there.

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

#57

Post by pjmlp »

forrestthewoods wrote: post #53
pjmlp wrote: post #50

Earlier quoted context omitted.

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.

C++ modules do not exist in practice and probably never will.

Office team apparently is of another opinion, as Vulkan folks, and a few other early adopters.

You could just as well say that anything beyond C89 doesn't exist, given its prevalence in some circles.

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

#58

Post by 3836293648 »

grandempire wrote: post #54
pjmlp wrote: post #50

Earlier quoted context omitted.

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.

> best of all C++20 modules Do any compilers besides VS support this?

GCC supports it with a flag. C++23's import std is not there at all though.

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

#59

Post by forrestthewoods »

pjmlp wrote: post #57
forrestthewoods wrote: post #53

Earlier quoted context omitted.

C++ modules do not exist in practice and probably never will.

Office team apparently is of another opinion, as Vulkan folks, and a few other early adopters. You could just as well say that anything beyond C89 doesn't exist, given its prevalence in some circles.

Yes. There are a very small handful of early adopters in the year 2025 for a feature ostensibly added in C++20.

So, like I said, modules don’t exist in practice and I’d be shocked if in 2030 modules were considered normal.

C++11 was pretty game changing. C++14 and C++17 only took a few years to reach widespread adoption.

It’s very safe to require C++17 today. C++20 was a little slower and because of the modules fuckup it’s a bit inconsistent. But it’s largely fine to use.

C++23 probably needs another year or two. But also C++20 and beyond haven’t added much that’s worth upgrading for.

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

#60

Post by 3836293648 »

qalmakka wrote: post #46
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).

C++ concepts are a failure due to them only checking one side of the contract. And the other is basically impossible to implement without breaking other parts of the language
Post reply on HN