Andrei's list of barriers to D adoption

[Brad Roberts via Digitalmars-d]

On 6/7/2016 12:52 PM, Walter Bright via Digitalmars-d 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. There are omissions possible either way.

Yes, either direction has the probability of being incomplete.  However, 
when the disallow by default and allow only explicitly activities is 
_far_ more correct in the face of omissions.  In the case of an omission 
of something that should be allowed, you haven't discovered a violation 
of safety, you've discovered a place to allow additional safe code.

To use an analogy, would you trust a security model where the list of 
people not allowed to withdraw from your bank account be a whitelist or 
a blacklist?

> Another issue is implementing such a spec. The "disapproved" list is how
> the compiler works, 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.
>
> 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.

Yes, it's hard to implement.  Shrug, you signed up for it.