On Fri, Aug 17, 2018 at 05:26:48PM +0000, jmh530 via Digitalmars-d wrote: > On Friday, 17 August 2018 at 14:26:07 UTC, H. S. Teoh wrote: > > [...] > > And that is exactly why the whole implementation of @safe is > > currently rather laughable. By blacklisting rather than > > whitelisting, we basically open the door wide open to loopholes -- > > anything that we haven't thought of yet could potentially be a > > @safe-breaking combination, and we wouldn't know until somebody > > discovers and reports it. [...] > Fundamentally, I see it as a good idea. Walter has talked about how > important memory safety is for D. People thinking their @safe code is > safe is a big problem when that turns out to not be the case. Imagine > the black eye D would have if a company was hacked because of > something like this?
Indeed. > IMO, the problem is that you can't just replace @safe as it is now. > You could introduce something like @whitelist or @safewhitelist and > begin implementing it, but it would probably be some time before it > could replace @safe. Like when @whitelist is only breaking unsafe > code. The way I envision it is that the implementation would begin as a separate topic branch in the dmd repo, and gradually brought up to the point where it begins passing the testsuite. The good thing is that nowadays with our CI system put in place, any breakages caused in major D projects like vibe.d would be detected by the autotester, so we can immediately fill in any obvious missing whitelist items. Then we'd merge it into master but controlled by a command-line switch, say -dipxxxx if we put it under a DIP, and put out for 1 or 2 releases. People who depend on @safe can then opt in to try it out, and report any bugs (missing whitelist items) that they find. We fix those bugs until no more bugs are reported. Then we make -dipxxxx the default, perhaps with a reverse switch for reverting to the old @safe implementation just in case some projects out there depend on it but haven't gotten around to reporting bugs in the new implementation or whatever. After another release or so, we finally remove the switch and delete the old implementation. Then going forward, we will have eliminated @safe loopholes pretty much completely (the only exception being codegen bugs), and the only likely bugs are missing items in the whitelist. Which should be much more manageable and much less disastrous -- the worst that can happen is that somebody tried to do something legal and got rejected by a big fat compiler error. As opposed to today's situation, where somebody tries something illegal and the compiler fails to detect it, and nobody even know there's a problem until it becomes an exploitable bug that causes a security problem. Given today's security climate, this would be utterly disastrous for D's reputation. T -- It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton