SubjectToChange

0% inflation would still be undesirable. First of all, introducing any sort of deflation is undesirable and dangerous. Second of all, there are so many causes of inflation that it's practically impossible to control them. But fundamentally there is an issue of time and labor. For instance, a landscaper doing work on my property this week is providing me with far more value than the landscaper who did work for me 20 years ago. Likewise, a car right off the production line is more valuable than an identical model that has been sitting in storage for a decade. Simply put, the value of labor cannot be separated from the time in which that labor was performed. Over a long enough period of time, the value of any labor becomes practically nonexistent. Therefore, even if it were possible to maintain a 0% inflation rate, doing so would be distorting the market.

Yes, savings should have a cost and/or risk associated with them. Furthermore, it’s insane to expect otherwise.

Absolutely not. Between someone with near zero net worth and someone with $100 billion net worth, inflation will cost the former almost nothing and the latter billions. In a deflationary environment a billionaire gets rewarded for merely existing while everyone else is starving for cash.

But if your goal is just to blow up the economy, then sure, a deflationary spiral is a potent poison.

Electronics have become cheaper through gargantuan investments of capital. Such investments are actively discouraged by deflation.

And in an inflationary world, you can just park your money in government bonds (effectively returning it back to the Fed) to beat inflation most of the time. Inflation doesn't force you to spend your money productively

Putting your money in government bonds or an interest earning savings account is by definition, putting your money to work. Sure, you aren’t doing anything with it, but whoever is paying you interest is only doing so because they expect to make more money than they borrowed.

Until customers care about performance/optimization, most businesses won't care. Eventually there will come a day where hardware will stagnate sufficiently to incentivize software efficiency.

Based on what? FP advocates like performance as much as anyone else.

They need this because the performance characteristics of pure functional programming is pretty dogshit.

Research languages like ATS show that functional programming doesn't come at the price of performance.

Sometimes one implementation's red box is better than another implementation's green box.

Clang supports the majority of C++20. The biggest blocker on coroutines is a Windows ABI issue and concepts will be ready after a few DRs are polished off. Basically, other than some minor CTAD and non-type template parameter enhancements, the biggest feature lagging behind are modules. IMO, I'm not ready for modules, my dependencies are not ready for modules, neither is my IDE nor my build system. So, for my interests, C++20 support in Clang is more than sufficient.

Apple and Google are perfectly fine with C++17 for their purposes, ...

Well, yes, and they will likely be using C++17 for quite a bit longer. In particular, not only is C++20 a massive update to the language, but the rate of development in the llvm-project has far exceeded the rate at which maintenance capacity can be increased. Not to mention a myriad of other issues, notably the architectural problems in Clang.

Anyway, such a pessimistic view of Clang/LLVM is unwarranted IMO. I have yet to see any metrics that imply their abandonment. Also, considering that Google is likely closer to 300 million LOC than 200 million, they really don't have a choice. Likewise for Apple unless they’ve given up on WebKit and LLVM for Swift.

I doubt Vulkan, a low-level graphics API with compute shaders, could ever directly compete with CUDA, a pure play GPGPU API. Although it isn't hard to imagine situations in which Vulkan compute shaders are sufficient to replace and/or avoid CUDA.

LLVM IR is a great accomplishment, but the design of Clang causes tremendous pain. In particular, the lack of any higher level IR(s) in Clang result in tremendous complexity, poorer diagnostics, and missed performance optimizations. Moreover, while initiatives like ClangIR[1] may exist, the fact is that a transition to MLIR will be long and messy, to say the least. Indeed, such a transition would likely involve the complete duplication of Clang internals while downstream implementations migrate. In comparison an implementation like GCC is free to define and modify new IRs as needed, e.g. GIMPLE has three major forms IIRC.

[1]: https://llvm.github.io/clangir//

Of course this isn’t to be dismissive of GPUs, they are a welcome addition to the compute stack. But the humble CPU should not be underestimated.

In general glibc maintains an extremely stable ABI[1]. Forwards compatibility in both glibc and libstdc++ is something many companies depend on for their mission critical applications, and it's the entire reason Red Hat pays developers to maintain those projects.

[1]: https://abi-laboratory.pro/index.php?view=timeline&l=glibc

It’s undefined behavior and there are justifiable reasons for being so. Requiring otherwise implies that implementations must exhaustively check every code path in a function. Such an analysis is extremely expensive, and even practically impossible for sufficiently complicated code, it also would need to work across translation units, e.g. akin to whole program optimization. Not to mention cases like linking against a binary library in which the compiler has nothing to analyze at all, or when a functionally impossible non-return path is found but the compiler can not prove to itself that it’s unreachable.

Ultimately there are situations in which non-void functions do not have a return value. Moreover, it is certain that a non-trivial amount of code is relying on such behavior. Therefore is unreasonable to make implementations non-conformant and it’s impossible to decide what a reasonable behavior should be otherwise, hence the behavior being undefined.

As an intermediate step they can at least specify the sized of types that are de facto fixed.

Why hurt non-standard platforms and encourage the use of poorly named integer types? Anyone who cares about this is already using fixed width types.

Sigh. Well it's good that I don't have to deal with this attitude in Rust at least!

Oh, and Rust doesn’t recommend using linting or code formatting tools like clippy or rustfmt?

By all means, use Rust if it’s an option for your needs. C++ is a very old language with all sorts of compromises.

But there is a lot of interest. CppCon has multiple talks on how the language is too complex and/or what paths could be taken to simply it.

I guess it doesn't matter much now since C++ is the new Fortran,…

C++ isn’t the new Fortran, it’s the new C. Fortran had ultimate primacy in the numerical code domain, C++ is used there too but almost everywhere else too.

… but there are so many little things they could fix with a -std= flag.

The problem is that any change to behavior will break code. And in the cost benefit analysis, making the language more accessible to potential new users doesn’t, and shouldn’t, take priority over current users. Now, there is a balance to strike, but simplifying C++ basically must be done through adding new features and interfaces.

Reaching the end of a function the should return a value but doesn't should be an error by default.

There are some nuance around this, but in the general compiler warnings/attributes and static analysis can do catch the cases of interest. Even if the language was changed to require this, I doubt implementations could actually check all code paths in every function.

char is 8 bits

Recommend using fixed width integer types instead?

require braces for if & for bodies

This isn’t a problem I see beginners usually having. But this is a style of code I’ve seen in many high profile code bases and it would be a . Anyway, aclang-tidy check is enough to enforce this.

make vector::operator[] range checked by default (and add an unchecked version)

The checked version already exists as .at(). It’s regrettably not the default, but again, changing such behavior would be far too inconvenient for the billions of lines of code out there.

I guess by the time you get to the point of proposing changes to C++ you have Stockholm syndrome.

There is a lot of behavior that experienced C++ developers simply get used to, e.g. std::map[]. However the reason for the lack of proposals for fixing basic problems is that they’re DOE and/or equivalent to choosing an ant-hill to die on.

I guess they did add string::starts_with at least. After like 30 years.

Utility functions are nice but they are hardly the most pressing issues facing C++ users.

I 100% agree. Although I have a keen interest in Rust I can’t see it offering any unique value to the GPGPU or HPC space. Meanwhile C++ is gaining all sorts of support for HPC. For instance the parallel stl algorithms, mdspan, std::simd, std::blas, executors (eventually), etc. Not to mention all of the development work happening outside of the ISO standard, e.g. CUDA/ROCm(HIP)/OpenACC/OpenCL/OpenMP/SYCL/Kokkos/RAJA and who knows what else.

C++ is going to be sitting tight in compute for a long time to come.

There are advanced real time cores like the Arm Coretex-R82. In fact many real time systems are becoming quite powerful due to the need to process and aggregate ever increasing amounts of sensor data.