Earlier quoted context omitted.
What is your current language of choice, both C and C++ have the same problems as what you just described. Regarding ownership transfer it is even worse in C, what if you forget, after moving an object out of a variable, to set that variable to NULL, then free that variable, that's a use after free. At least in C++ you have move semantics although it is still error prone. In rust it's a compiler error. Copy and Clone…
Well, i dont use C++ much(i'm FW engineer, most of my stuff is in C). The std in C is simple and explicit. For Ex: I can make an educated guess how memcpy() work by looking at its signature. It takes pointer to src and destination, and size, so i can guess it does not allocate any new memory(or if it has, it has to be some kind of optimization reason). Another example is strstr(), it returns pointer to a piece of mem…
> piece of memory i provided to it, so i can safely do some pointer math with the return value.
Except pointer math is never going to be safe in C, a particular case might be bugfree but it is not safe. Moreover, nothing in the C language says that the provenance of the output pointer matches the provenance of the input pointer (it could take a reference to a pointer from some other thread while that other thread is freeing that memory). In rust you will pass a pointer and get a pointer back with the same lifetime, then you can safely use the pointer in that lifetime bound: the provenance is part of the signature. So in this case, you are incorrectly assuming things from the C signature while the corresponding rust signature definitively tells you.
So yeah, if you learn more about rust then you will see that in fact it tells you more than the corresponding C signatures.