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

[Steven Schveighoffer]

On 3/25/20 11:36 PM, bachmeier wrote:
> On Wednesday, 25 March 2020 at 18:04:33 UTC, Steven Schveighoffer 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.
>>
> 
> Let me put it differently. Suppose I release a linear algebra library 
> that's a wrapper over a C library. Nobody using D the way it's supposed 
> to be used can use my library. It just doesn't make sense for a language 
> that claims strong C interoperability.

I understand, it is a good point.

To rephrase (to make sure I understand): Today, people open an editor, 
start a main function, and import your library, and everything works. 
They don't realize or care that they are using @system code.

If this DIP gets accepted, they open their editor, start a main 
function, which is now implied safe, and they cannot use their library 
without marking their main @system. It's an extra step, and one that 
forces them to think about what they are doing in terms of safety.

So even though nothing has changed exactly (things that were @system are 
still @system), the status quo for D code changes, which means now your 
library moves from by-default acceptable, to you need to go into 
dangerous territory to use this library.

I still think this is the appropriate path. We cannot continue to ignore 
memory safety as a secondary concern just because C code is by-default 
unsafe. Memory unsafe HAS to be opt-in for any new modern language to 
succeed.

I think for sure people need to have guidance as to what makes sense. I 
think unlike something like Rust, the path to using all @system code is 
pretty straightforward in D. So yes, it's a burden, but with guidance 
and the tools we have, it should be a small burden.

And in actuality, most D code is @safe, so for most D code out there, 
this is not going to be a huge problem. You will have to mark few 
things. Wrappers/bindings for C libraries are going to be an exception, 
and that's just the pain we have to deal with. Either use trusted 
markings to make everything safe (after verification), or just punt to 
the user.

> Anyway, I'm going to let this die, because nobody else sees it as an issue.

I think it's worth discussing, and I hadn't thought of this perspective, 
so thanks for clarifying.

-Steve