On Friday, 4 August 2017 at 08:46:05 UTC, Walter Bright wrote:
On 8/4/2017 1:33 AM, RazvanN wrote:
That could have never happened if they would have used D with
@safe
That's mostly true, but not absolutely true.
1. There can be bugs in D's @safe checking and inference.
2. Function interfaces (such as in C interface files) are
labeled @safe or not, and the D compiler has no way to check.
Hence, functions can (and have been) mislabeled.
On the other hand, @safe does greatly reduce the attack
surface. And as I've prognosticated before, the utter lack of
machine checkable memory safety in C will herald the end of its
use in anything connected to the internet.
So, you agree that @safe cannot solve the problem because of C
function interfaces and 'lack of machine checkable memory safety
in C'. In this case, why does @safe relies on static analysis in
CT and type inference when memory safety is determined by the 'C
memory sate' at RT? Either @safe is wrongly presented (it is not
memory safety tool, but something else) or (if the intention was
to provide memory safety tool) it is a flawed feature.
Of course, memory safety is impossible in C. In my opinion, D's
@safe is wrongly marketed as a fully safety tool (look at a user
above). This is dangerous, because leads to unfounded assumptions
and later disappointment.
By the way, I see that DIP 100 followed the same way - impose
static type restrictions in CT to prevent memory errors. I
believe, due to growing language complexity any combination of
resctrictions can have loopholes. Back in 2013 I was collecting
type system holes and posted them in Bugzilla after your request.
It appears, that scope has its own loopholes too [1].
[1] https://issues.dlang.org/show_bug.cgi?id=17718
