Is @safe still a work-in-progress?

[Steven Schveighoffer]

On 8/17/18 1:26 PM, jmh530 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.
>>
>> Sadly, it seems there is little interest in reimplementing @safe to 
>> use whitelisting instead of blacklisting.
>>
>>
>> T
> 
> 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?

This will always be a possibility thanks to @trusted.

> 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.

I have to say, I don't see how this all helps.

In theory, black-listing and white-listing will get you to the same 
position. Mechanisms to get or use pointers aren't really being added to 
the language any more, so the set of "things" to "list" either black or 
white is finite.

In this thread, we are talking about something that should have been 
black-listed LONG ago, but was not because it was "too useful" (i.e. 
would break too much code). If @safe code was white-listed, nobody would 
use it until it was finished, so it would be theoretical anyway.

Nobody wants a feature that is @safe, but not useful.

However, a bigger problem is that we have a bug that is "fixed" (slicing 
static arrays) but only if you use a feature that doesn't work correctly 
(dip1000). Why? I think the bug should be reopened until dip1000 is the 
default, or it simply gets fixed (i.e. without requiring dip1000).

-Steve