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
