[sirwhinesalot]

They're at least spatially memory safe (bounds checks), which already helps a lot since buffer overflows account for more than 20000 vulnerabilities over the years.

C is allergic to fat pointers for reasons I don't understand and the bounds safe .at() method of std::span in C++ is only coming in C++26.

These two languages have a serious attitude problem towards security.

Also Delphi uses automated reference counting, bringing it more inline with Swift rather than your typical C++ codebase. (though sadly the implementation is a bit error prone due to the object/interface reference distinction)

[eqvinox]

> C is allergic to fat pointers for reasons I don't understand

I do understand not making "some_type *" a fat pointer, since that makes it difficult to interface with another language's fat pointers.

On a library/API level lots of libraries use fat pointers of various incompatible kinds. The best thing C could IMHO do is add a fat pointer variant to the ISO C standard library functions, plus syntactic sugar. Unfortunately this chafes against "conservative" inertia :(

[sirwhinesalot]

Nobody wanted to make "some_type *" a fat pointer, everyone wanted a new syntax. Maybe it was an issue of constant bikeshedding on what exactly that syntax should have been? I like Walter Bright's proposal of "some_type[..]".

[crq-yml]

Agreed, there's profound difference between "default runtime checks for common issues, can inline a toggle to disable" (which describes both Delphi and Ada) and the C "do it yourself kid" or C++ "we have a template for that" approach.