Is @safe still a work-in-progress?

[Atila Neves]

On Friday, 17 August 2018 at 08:23:20 UTC, vit wrote:
> On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis 
> wrote:
>> On Friday, August 17, 2018 1:19:25 AM MDT Peter Alexander via 
>> Digitalmars-d wrote:
>>> [...]
>>
>> That particular bug is a duplicate of 
>> https://issues.dlang.org/show_bug.cgi?id=8838, which was 
>> closed as fixed based on the fact that -dip1000 fixes the 
>> problem by treating marking the slice of a static array with 
>> scope. It's still quite broken without -dip1000 though.
>>
>> [...]
>
> What's the state of -dip1000?

I've been using -dip1000 a lot lately. I hit two bugs yesterday. 
When it works, it's great, _except_:

. @safe isn't default
. -dip1000 isn't default
. Good luck figuring out why your template functions aren't @safe 
and coaxing the compiler to tell you why it's inferring the 
attributes it is. Bonus points if it's a Phobos function so you 
can't slap `@safe` on its definition.

Take excel-d for instance. The other day somebody filed a bug 
because Excel was crashing when they wrapped some D code that 
uses std.regex. After investigating I found out that regex 
memoizes the string with the regular expression in it, 
effectively escaping the string passed from Excel to the D 
function. Unfortunately for everyone involved, that string came 
from a region allocator, and after bumping the pointer back, boom.

Telling people to not escape reference parameters doesn't really 
work, because nobody will read that part of the README, and, as 
in the example above, the user didn't even know they were doing 
it!

Ok, so as a good library author, I tried to make it a 
compile-time error to shoot yourself in the foot that way, and I 
did. Great, right? Well, no. I can't force the user to write 
@safe functions, much less to compile with -dip1000. I changed 
the example XLL to use -dip1000 because more likely than not 
users will copy the example and edit it. But I can't force them 
to write @safe functions, and if they don't (the likeliest 
scenario given it's not the default), they'll be able to escape 
whatever it is they want, Excel will crash, and the compiler will 
be ok with it.

And if they _do_ write @safe functions and compile with -dip1000, 
chances are at some point they won't understand the compiler 
error message, make their function @trusted and... crash.
I don't know that because I have a crystal ball, I know that 
because I did it myself this week. Twice.

Did I mention the bugs? I wrote about my interesting experiences 
from this week with -dip1000 here:

https://forum.dlang.org/post/lxavagebcmaxjdzisyfk@forum.dlang.org