That's perfectly fine. It's a standardization process. Its goal is to set in stone a specification that everyone agrees to. Everything needs to line up.
In the meantime, some compiler vendors provide their own contracts support. If you feel this is a mandatory feature, nothing prevents you from using vendor-specific implementations. For example, GCC has support for contracts since at least 2022, and it's mostly in line with the stuff discussed in the standardization meetings.
Still no contracts?
In line with the release process for C++ standard specifications, where standards ship every 3 years but alternate between accepting new features and feature freeze releases, C++23 was the last release that was open to new features. This would mean C++26 is a feature freeze release following the new features introduced in C++23.
If you write it down it is documentation.
I think you're not getting the point.
It matters nothing if you write down something. For a project, only the requirements specification matters. The system requirements specification document lists exactly what you need to deliver and under which conditions. It matters nothing if you write a README.md or post something in a random wiki.
Requirements are not the same thing as specifications either, but both are documentation!
https://en.wikipedia.org/wiki/System_requirements_specification
Naked pointers are just too stupid for modern C++ ;)
Anyone who works on real-world production software written in C++ knows for a fact that pointers are a reality.
Also, there are plenty of frameworks who employ their own memory management frameworks, and raw pointers are perfectly fine in that context. For example, Qt uses raw pointers extensively because It's object system implements an object ownership system where each object can have child and parents, and you can simply invoke deleteLater() to free the whole dependency tree when you no longer need it.
C++ can be written to be safe. I don’t think WH is the right authority to issue this warning. Naming C++ rather than going after specific features is unfair.
I suspect that the white house just received a report from some people in the industry stating that faulty software is vulnerable to attacks from bad actors, and from that basis they just went the simplistic path of arguing that 1) lots of software is written in C++, 2) that software has bugs, therefore if we don't use C++ then we won't have bugs.
As a branch of government, their role is not to evaluate technical merits of proposals but to hear what their representatives have to say.
Honestly his defence is rather weak. “It’s been improving and there are ways to use it safely.”
I think it's a very good and clear point to make.
Some programming languages are blindly deemed "safe" in spite of supporting unsafe memory management strategies, and somehow not enforcing those rules does not render them unsafe.
Why is this logic not applied to C++?
I use C++ all the time, undefined behavior is not something I encounter ever. I run undefined behavior sanitizer often.
From the looks of some of the posts showing up in this thread, I doubt the bulk of the commenters portraying UB as the root cause of any problem have any experience at all with C or C++. They are clearly resorting to unrealistic strawmen to pretend UB is something that it clearly is not. That just goes to show their technical background and the substance behind their claims. I really don't know how this helps advocating for Rust.
Each implementation that exhibits different behavior doubles the amount of testing needed to ensure cross-platform correctness.
Not really. The whole point of undefined behavior is that the standard intentionally leaves out any definition of behavior, or the program is already fundamentally broken.
If you insist on unwittingly using code that relies on undefined behavior, you're the one mindlessly writing broken code. It's not the standard's fault that you're adding bugs.
The irony is that compiler implementations also leverage undefined behavior to save you from yourself and prevent programs to crash when they stumble upon the mess you've done with the code.
But if you want me to give concrete examples of how problematic git UI can be, you are so far removed from reality and are neglecting the very visible and vocal struggle git beginners have.
And yet you were not capable of providing a single example. You managed to put together personal attacks, but no example.
At that volume of communication, the Github workflow of “clicking through stuff” is way inferior to an efficient email workflow. Essentially, your workflow turns into email anyways because its the only sane way to consume based on push (...)
I don't agree. Any conversation on pull requests happens through issues/tickets, which already aggregate all related events and are trivially referenced through their permanent links, including through the Git repo's history.
It is branching away from Java, even if it still uses it primarily.
I'm sorry to tell you, but I assure you it is not. Some small subset of teams uses non-java tech stacks but that's because they have very particular requirements, such as being android apps or running on Linux devices. The bulk of the company heavily standardized on Java and has no plans to ever move away from it.
Unusually, off the top of my head, I happen to know more .NET developers working there than Java developers, and interestingly they develop one of the services on AWS.
First of all AWS is not Amazon.
Secondly, I can tell you for a fact that C# is one of the rarest tech stacks at Amazon. Even Amazon's internal build system does not support it.
I'm afraid you're talking about stuff you know close to nothing about.
Why would anyone subject themselves to explore nonstandard and improvised solutions to try to fit a usecase that fails to meet your needs to a tool that was not designed to support it?
Do people enjoy creating their own problems just to complain about them?