4 ms·

The programmers don't want the code in the paper to work correctly, though. What they want is for the C spec to rule it incorrect without also ruling a lot of e

• Animats 8y ago
  C needs an ownership model, but it's almost hopeless to retrofit one. This is a very limited proposal regarding some obscure aliasing problems. I looked at C and C++ ownership years ago. I had more limited goals than the Rust borrow checker. I was thinking in terms of permissions - read, write, delete, and keep, combined with reference counting. Keep permission means you can take a copy of a pointer and export it to a larger scope. Like passing in a pointer to an object to be added to a collection. The stored pointer will outlive the return from the function that added it to the collection. It "kept" it. If you pass a reference to an object without keep permission, the called function can't keep it. So the language does not have to increment the reference count. In fact, you don't even have to pass the reference count, just the raw object pointer. So objects passed by non-keep reference to a function incur no extra overhead. That's a very common case. "Keeping" is relatively rare. So you get reference count allocation without much overhead. Workable, but a dead end politically in C. Rust essentially makes all references "non-keep", unless you explicitly use reference counts.