Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[Jonathan Marler]

On Wednesday, 25 March 2020 at 19:27:22 UTC, Jonathan M Davis 
wrote:
> On Wednesday, March 25, 2020 12:04:33 PM MDT Steven 
> Schveighoffer via Digitalmars-d wrote:
>> On 3/25/20 1:34 PM, bachmeier wrote:
>> > On Wednesday, 25 March 2020 at 14:10:18 UTC, Steven 
>> > Schveighoffer wrote:
>> >> Everything else in the DIP is possibly annoying to deal 
>> >> with but at least doesn't silently destroy the meaning of 
>> >> @safe.
>> >
>> > To be perfectly honest, I can't imagine D being a sensible 
>> > option for someone wanting to work heavily with C code if 
>> > you have to add pointless annotations and constantly deal 
>> > with compiler errors. It's not a matter of annoyance, it's 
>> > simply impractical to add that kind of overhead, 
>> > particularly if someone else is involved. If you're using C, 
>> > you're well aware that it's not going to be safe. Rust was 
>> > designed for *writing* safe code, not for wrapping C 
>> > libraries, which is maybe the main use of D right now.
>>
>> This is overblown. Adding @system: at the top of a c library 
>> header is not hard.
>>
>> Tools which generate headers for C libraries (e.g. dpp) can
>> automatically do the right thing.
>
> Not only that, but if _any_ function is automatically marked as 
> @safe when the compiler can't verify that it is, and no 
> programmer has verified that it is and marked it with @trusted, 
> then @safe is borderline pointless and useless, because it's 
> not actually guaranteeing memory safety. We have enough of a 
> problem with programmers incorrectly using @trusted without the 
> compiler doing it. @safe needs to provide actual compiler 
> guarantees, or it just provides a false sense of security. 
> extern(C) functions ultimately exist in the call stack of every 
> D program (even if most of them are buried in D code rather 
> than being used directly by the program), and to have those 
> treated as @system with no verification basically throws 
> @safe's guarantees out the window.
>
> I agree with Walter's assertion that the DIP applies to 
> extern(C) functions unless it says otherwise, but that being 
> the case, the DIP needs to be fixed so that it does not apply 
> to extern(C) functions, or it will do _far_ more damage than 
> good.
>
> - Jonathan M Davis

I agree that safe is almost pointless if it's not on by default.

That being said, in practice I'm not sure how much benefit @safe 
actually provides. In theory it sounds nice.  It could help audit 
code, but for me, I audit all my code the same whether or not 
it's safe.  So for me the whole feature seems kinda pointless. 
Maybe this is different for others?  Does anyone have any real 
life examples/experience where @safe has helped?  Has the benefit 
warranted the cost to manage these tags throughout your code? Do 
we have any projects that are already using this behavior by 
putting "@safe:" at the top of every file?  Does anyone have any 
pointers to projects that have done this?  Have they seen any 
benefits from doing so?