News for hackers. Stuff that matters.
Re:How C++ Resolves a Function Call by whatshisface on Tuesday March 16, 2021 @12:06PM (#26478644)
C++ will structurally never have a borrow checker, because it's simply not designed in a way for that to be possible.
Re:How C++ Resolves a Function Call by ncmncm on Tuesday March 16, 2021 @06:29PM (#26484053)
Correct.

But a borrow checker does not change the set of possible programs. It only identifies the subset of possible programs that would need "unsafe" blocks.

In the absence of a borrow checker, libraries are left to carry the responsibility to define an API that is hard to misuse. Such an API could be slower than what one would define for a library to be used under a borrow checker. But code written to satisfy a borrow checker is sometimes slower than code that doesn't need to.

Re:How C++ Resolves a Function Call by whatshisface on Tuesday March 16, 2021 @07:02PM (#26484349)
>But a borrow checker does not change the set of possible programs.

Once you have Turing completeness you have the full set of possible programs, end of story. Languages aren't about changing the set of possible programs, they're about making good ones easier to write, and bad ones harder.

Re:How C++ Resolves a Function Call by ncmncm on Wednesday March 17, 2021 @03:11AM (#26487527)
Then there is nothing but ones and zeroes, and nothing to compare, and no insight to be had.

Yet, C++, D, and Rust are much more like one another than any of them is like any other language. Your Turing Completeness tells you less than nothing about any important distinction between them.

Re:How C++ Resolves a Function Call by WalterBright on Tuesday March 16, 2021 @04:20PM (#26482295)
D has a prototype borrow checker now. I'll be talking about it at the April NWCPP meeting.