Andrei's list of barriers to D adoption

[Timon Gehr via Digitalmars-d]

On 07.06.2016 21:52, Walter Bright wrote:
> On 6/7/2016 11:32 AM, Timon Gehr wrote:
>> 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.
>
> I don't see how it is any different painting the fence from one
> direction or the other.

The fence is infinitely long, your painting speed is finite and people 
will be looking at the fence mostly at the left end.

> There are omissions possible either way.
> ...

In one way, an omission means you are potentially tracking down memory 
corruption inside a huge codebase by grepping for @trusted, until you 
notice that the issue is in @safe code.

In the other way, an omission means you are getting a spurious compile 
error that is easily worked around.

> Another issue is implementing such a spec. The "disapproved" list is how
> the compiler works,

It is how the compiler fails to work.

> and makes it reasonably straightforward to check the
> implementation against the list. It's quite a mess to try to tag
> everything the compiler does with approved/disapproved, so you wind up
> in exactly the same boat anyway.
> ...

The compiler should work by inclusion too.

> In any case, writing such a large specification covering every semantic
> action of the of the language is way, way beyond being a bugzilla issue.
> ...

Does not apply. The bugzilla issue can be fixed by disallowing all code 
in @safe. Also, why not just close the bugzilla issue _after_ there is a 
more adequate replacement?

> If you want to take charge of writing such a specification DIP,
> please do so.
>

If you think progress on this matters, why are you arguing against it?