Contradictory justification for status quo

[Andrei Alexandrescu via Digitalmars-d]

On 2/27/15 7:33 AM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Feb 27, 2015 at 06:02:57AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> [...]
>> Safety is good to have, and the simple litmus test is if you slap
>> @safe: at the top of all modules and you use no @trusted (or of course
>> use it correctly), you should have memory safety, guaranteed.
> [...]
>
> @safe has some pretty nasty holes right now... like:
>
> 	https://issues.dlang.org/show_bug.cgi?id=5270
> 	https://issues.dlang.org/show_bug.cgi?id=8838
> 	https://issues.dlang.org/show_bug.cgi?id=12822
> 	https://issues.dlang.org/show_bug.cgi?id=13442
> 	https://issues.dlang.org/show_bug.cgi?id=13534
> 	https://issues.dlang.org/show_bug.cgi?id=13536
> 	https://issues.dlang.org/show_bug.cgi?id=13537
> 	https://issues.dlang.org/show_bug.cgi?id=14136
> 	https://issues.dlang.org/show_bug.cgi?id=14138
>
> There are probably other holes that we haven't discovered yet.

Yah, @safe is in need of some good TLC. How about we make it a priority 
for 2.068?

> All in all, it's not looking like much of a guarantee right now.  It's
> more like a cheese grater.
>
> This is a symptom of the fact that @safe, as currently implemented,
> starts by assuming the whole language is @safe, and then checking for
> exceptions that are deemed unsafe. Since D has become quite a large,
> complex language, many unsafe operations and unsafe combinations of
> features are bound to be overlooked (cf. combinatorial explosion), hence
> there are a lot of known holes and probably just as many, if not more,
> unknown ones.

I'd have difficulty agreeing with this. The issues you quoted don't seem 
to follow a pattern of combinatorial explosion.

On another vein, consider that the Java Virtual Machine has had for 
many, many years bugs in its safety, even though it was touted to be 
safe from day one. With each of the major bugs, naysayers claimed it's 
unfixable and it belies the claim of memory safety.

A @safe function may assume that the code surrounding it has not broken 
memory integrity. Under that assumption, it is required (and 
automatically checked) that it leaves the system with memory integrity. 
This looks like a reasonable stance to me, and something I'm committed 
to work with.

> Trying to fix them is like playing whack-a-mole: there's
> always yet one more loophole that we overlooked, and that one hole
> compromises the whole system. Not to mention, every time a new language
> feature is added, @safe is potentially compromised by newly introduced
> combinations of features that are permitted by default.

There aren't many large features to be added, and at this point with 
@safe being a major priority I just find it difficult to understand this 
pessimism.

Probably a good thing to do, whether you're right or overly pessimistic, 
is to fix these bugs. In the worst case we have a slightly tighter 
"cheese grate". In the best case we get to safety.

> Rather, what *should* have been done is to start with @safe *rejecting*
> everything in the language, and then gradually relaxed to permit more
> operations as they are vetted to be safe on a case-by-case basis.

Yah, time travel is always so enticing. What I try to do is avoid 
telling people sentences that start with "You/We should have". They're 
not productive. Instead I want to focus on what we should do starting now.

> See: https://issues.dlang.org/show_bug.cgi?id=12941

I'm unclear how this is actionable.


Andrei