Andrei's list of barriers to D adoption

Observer via Digitalmars-d digitalmars-d at puremagic.com
Sat Jun 11 07:12:46 PDT 2016


On Tuesday, 7 June 2016 at 20:41:21 UTC, Jonathan M Davis wrote:
> In principle, I think that you're very right that @safe needs 
> to be implemented as a whitelist. Security in general does not 
> work as a blacklist, and I think that @safe has the same 
> problem. The problem is code breakage. Even assuming that the 
> change in implementation were straightforward (and I have no 
> idea whether it is or not), it would be pretty much guranteed 
> that we would break a lot of code marked @safe if we were to 
> switch to a whitelist. Some of that code is not truly @safe and 
> really should be fixed, but just throwing the switch like that 
> is too sudden. We'd probably be forced to have both a whitelist 
> and a blaklist and treat the whitelist results as warnings 
> temporarily before switching fully to the whitelist 
> implementation. And that's likely feasible, but it seems like 
> it would be a bit of a mess. So, I don't know if we reasonably 
> can switch to a whitelist or not. But I think that it's clearly 
> that we ideally would.

I think you meant "treat the non-whitelist results as warnings".

Seems to me the proper answer is simple.  Stuff on the whitelist
should pass without comment.  Stuff on neither the whitelist nor
the blacklist should generate warnings.  Stuff on the blacklist
should generate errors.  A compiler flag similar to gcc's -Werror
that turns all warnings into errors would allow the end-user to
select whether or not to worry, during a phase of transition.

This way, those warnings could be pushed back upstream to the
compiler maintainers as "hey, your whitelist/blacklist division
omits certain real-world cases".  And gradually, the graylist
would be narrowed over successive compiler releases.


More information about the Digitalmars-d mailing list