It’s very hard for “Safe C++” to exist when integer overflow is UB.
You could simply state you did not read the article and decided to comment out of ignorance.
If you spent one minute skimming through the article, you would have stumbled upon the section on undefined behavior. Instead, you opted to post ignorant drivel.
It’s used because the ones who use it have enough money to pay for any problems that may arise from it’s use, (...)
That's laughable. Literally the whole world uses it. Are you telling me that everyone in the world just loves to waste money? Unbelievable.
With what in mind? Evading NULL?
Depends on your perspective. It's convenient to lean on type checking to avoid a whole class of bugs. You can see this either as avoiding NULL or use your type system to flag misuses.
Languages that make use of references rather than pointers don’t have this Dualism. C# has nullable references and nullability analysis, and null as a keyword.
C#'s null keyword matches the monadic approach I mentioned earlier. Nullable types work as a Maybe monad. It's the same concept shoehorned differently due to the different paths taken by these languages.
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
C has always been (...)
I think you tried too hard to see patterns where there are none.
It's way simpler than what you tried to make it out to be: C was one of the very first programming languages put together. It's authors rushed to get a working compiler while using it to develop an operating system. In the 70s you did not had the benefit of leveraging half a century of UX, DX, or any X at all. The only X that was a part of the equation was the developers' own personal experience.
Once C was made a reality, it stuck. Due to the importance of preserving backward compatibility, it stays mostly the same.
Rust was different. Rust was created after the world piled up science, technology, experience, and craftsmanship for half a century. Their authors had the benefit of a clean slate approach and insight onto what worked and didn't worked before. They had the advantage of having a wealth of knowledge and insight being formed already before they started.
That's it.
I’m reasonably sure compilers can shift the if out. I believe it’s called “loop invariant code motion”.
That scenario would only apply if the condition was constant and specified at compile time. There's no indication on whether var1 or var2 are compile-time constants or predicates evaluated at runtime.
Like everyone has mentioned, because you want the data to persist across program runs.
RDBMS do not imply persisted data. There are plenty of databases which support or are designed explicitly to work as in-memory data stores. Perhaps the most popular one is SQLite, whose in-memory store is a popular choice.
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.
I think it would be beneficial for their community to take the wish for more credit more serious and try to make him feel welcome.
I think they did. Apparently the maintainer trusted the first-time contributor enough to propose tackling another bug.
If the goal is to get more contributions, I think that's exactly what should happen. I feel the kernel maintainer is being treated unfairly.
Whining about getting extra work feels like the author didn't intended to contribute anything else and just put all this reputation chips on that one isolated ticket.
A database carry the schema, structure, that allow you to validate that you are still having the structure you want.
So do all file formats.
SQLite is both a file and a database, but what I’m saying is that people shouldn’t mess with the file, but the database interface instead.
The same holds for all file formats: don't go around licking random bits in a file, use a client instead.
I have nothing against third party clients, the important thing is keeping the structure.
That's what file format clients are for, and anyone can even roll out their own if they want it.
The facts a DB use the Filesystem behind the scenes, is an implementation details the user shouldn’t be much concerned about, some DB can do without Filesystems.
That's really besides the point. The point is that it doesn't make sense to frame using databases over files as using a higher level client over persisted data.
No> Context is whatever makes sense to provide to a consumer to help them debug it or respond to it
So it's both optional and unspecified. This means it can't be parsed or relied upon, specially by consumers. It's useless.
the same basic idea as in the rfc under details.
No, it isn't. Contrary to your ad-hoc format, RFC9457 specifies exactly the data type of detail and what's its purpose. This allows third parties to reliably consume resources that comply with RFC9457 while your ad-hoc format leaves clients no option other than to ignore it.
IMO, it can’t easily be generalized. Some APIs may have context to provide, others may not.
It matters nothing what services can produce. What matters is whether clients can consume it. Your ad-hoc format fails to specify this field, which is optional, and thus leaves no option other than to ignore it. It's unusable.
Success is something that you can sniff for after deserializing, as IIRC Fetch API will not throw except for a network errors, even in the event of a 4XX or 5XX.
What the Fetch API does or does not do is irrelevant. The responsibility of putting together a response and generating the resource shipped with it lies exclusicely in your service. If it outputs a resource that is unable to tell clients what went on, that's a problem cause by both how your service is designed and the ad-hoc format it outputs.
The main take is that RFC9457 is well specified and covers basic usecases, while your ad-hoc format is broken by design. Thus when you describe the RFC as "overwrought", you're actually expressing the half-baked approach you took.
How do you explain C#?