On Thursday, 17 June 2021 at 12:52:40 UTC, Ola Fosheim Grøstad wrote:
>My take on this is that interfacing with C/C++ undermines @safe to such an extent that C/C++ interop isn't really as big of a selling point as it is made out to be (meaning you have to choose either @safe or C/C++ interop). I think that is a problem. If you have two big features then you shouldn't have to choose. The conception of @safe has to work well for people who write large application with lots of C/C++ interop.
No language can do this. C++ API does not provide any safety guarantees, so calling a C++ function means that it needs to be manually verified, or it's authors trusted, BY DEFINITION.
The only way around this would be to implement an automatic safety checker on C++ side. If it has to work out of the box on most real-world code, I don't think we will see such a complex checker in decades.
I suspect you're trying to say that because of the above, we would have to conclude that good C++ interop and memory safety guarantees should never be mixed in one language, D or otherwise.
If that's the case, the only conclusion I can draw is that D philosophy is fundamentally wrong from your point of view. D is all about letting the programmer pick the paradigm according to the situation, instead of being designed for just one of them. This philosophy is rooted so deep that if it proves to be just plain wrong, were best off to just ditch D and switch to other languages.
I sure hope that won't happen.