Andrei's list of barriers to D adoption

[Timon Gehr via Digitalmars-d]

On 07.06.2016 20:15, Walter Bright wrote:
> On 6/7/2016 10:44 AM, Timon Gehr wrote:
>> How do you know that some random @safe PR pulled into your project
>> does not
>> corrupt memory?
>
> @trusted and @system are designed to be greppable,

$ grep -r "@trusted" *
$ grep -r "@system" *

> i.e. you can look for
> them without needing a static analysis tool.

mixin("@tru"~"sted void foo(){ ... }");

Anyway, this is not actually the issue. One can hack the compiler such 
that it reports locations of @trusted functions easily.

I still don't know the code is memory safe if main is @safe and there 
are no @trusted functions in the code. The @safe subset should be 
specified and implemented by inclusion, such that it is obvious that it 
does the right thing. I don't know what's 'unspecific' about this. 
Closing holes one-by-one is not the right approach here. You don't know 
when you are done and might never be.