Simplification of @trusted

[Dukc]

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.