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.
