Andrei's list of barriers to D adoption

[H. S. Teoh via Digitalmars-d]

On Tue, Jun 07, 2016 at 12:49:55AM -0700, Walter Bright via Digitalmars-d wrote:
> On 6/7/2016 12:07 AM, Brad Roberts via Digitalmars-d wrote:
[...]
> > This minimization and deflection of real user feedback is rather
> > disappointing and somewhat insulting.  Instead, I'd prefer to see
> > acceptance that it's an actual issue and not hand waved away as not
> > really a problem of current, real, users.
> 
> I cannot do anything with handwaving statements, whether I accept them
> and hang my head in shame or not. Although I may have missed some, or
> some may not be tagged properly, I found only one bugzilla issue from
> you tagged 'safe':
> 
> https://issues.dlang.org/show_bug.cgi?id=13607
> 
> Here is the complete list of issues tagged with 'safe':
> 
> https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe&keywords_type=allwords&list_id=208819&query_format=advanced
> 
> Writing up specifically what problems you're having would be most
> appreciated.

I can't seem to find an issue I filed some years ago about @safe needing
to be whitelist-based rather than blacklist-based. Did it get closed
while I wasn't looking?

The problem is that D, being as complex as it is, has far too many
corner cases and unanticipated feature combinations, that there is
always going to be something that violates @safe in some way that we
hadn't anticipated.  Currently, @safe is implemented as what's
effectively a blacklist: code is assumed to be @safe by default, unless
they use one of a set of features deemed unsafe. This means
unanticipated unsafe corner cases will be assumed @safe by default.

A better approach would be to assume that *everything* is unsafe, and
then whitelist those operations that are verifiably @safe. Yes, at first
it will be almost impossible to write @safe code because the compiler
will complain about everything, but as the whitelist is expanded more
code becomes compilable in @safe, and we at least would have the
confidence that unanticipated corner cases will be assumed unsafe. If
they actually turn out to be @safe afterwards, we can always add them to
the whitelist, and in the meantime we have the confidence that no code
in the wild is actually unsafe while assumed to be @safe. Whereas right
now, it's hard to be confident that code marked @safe doesn't contain
some unexpected feature combination that is actually unsafe, but that we
just haven't caught it yet.


T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex." -- Simon St. Laurent on xml-dev