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

Aliak something at something.com
Sat Apr 4 08:34:48 UTC 2020


On Saturday, 4 April 2020 at 06:53:57 UTC, Walter Bright wrote:
> On 4/3/2020 2:06 PM, Steven Schveighoffer wrote:
>> I want to make sure you understand that we are not talking 
>> about extern(C) functions that are written in D.
>
> I understand totally what you are talking about.
>
>
>> But what should absolutely not compile is:
>> 
>> extern(C) int free(void *);
>> 
>> void foo(int *ptr) // now inferred @safe
>> {
>>     free(ptr);
>> }
>
> I understand your proposal. You want C functions without bodies 
> to be @system.
>
>
>> The fact that we cannot control where/how people define their 
>> prototypes means we have to be firm on this. They need to 
>> opt-in to @safe with extern(C), it cannot be default.
>
> On the other hand, special cases like this tend to cause 
> unexpected problems in the future. Experience pretty much 
> guarantees it. It's likely to be tricky to implement as well.

How are rules like:
1. All D functions are safe by default
2. All extern functions are system by default

Complicated or special cased? They look simpler than D’s 
conversion rules or function overloading rules. At the end, any 
rule can be called a “special case”.

>
> People remember simple rules. They don't remember rules with


Also 60-80% of people stick with defaults. The one thing I 
consistently see people get wrong in APIs and UX is that they 
make the choice that does the most damage the default.

I’ll leave this here for insight in to research on defaults: 
https://uxdesign.cc/design-by-default-the-impact-of-using-default-options-in-user-centered-design-926c4d24385c

> odd exceptions to them, that always winds up with trouble and

I think calling “you need to explicitly mark uncheckable 
functions as safe” an odd exception is highly exaggerating the 
situation.

> bug reports. Simple rules applied evenly lead to a compiler 
> that works and is reliable. I'm afraid the weight of all the 
> special rules will crush D.
>
> Now, as to what to do. I spent a few minutes and added 
> `@system:` in to the C headers in druntime for windows, posix, 
> and linux. Done. I hope someone else will do it for freebsd, 
> etc., if not I'll go do that to.
>
> > is going to cause huge issues.
>
> I doubt that for the simple reason that @system by default has 
> not caused huge issues.
>
> The rule is simple:
>
> "For a D module with a bunch of C declarations in it, start it 
> with `@system:`."
>
> It's not a hard rule to check. It's one line. D's C interface 
> has always relied on the user to get right. Recall that C 
> doesn't do any name mangling at all:
>
>   ----- mylib.di
>     extern (C) int addOne(int i);
>
>   ----- mylib.c
>     double addOne(double d) { return d + 1; }
>
>
> That'll link fine and yet fail at runtime. Oops! Calling it 
> @system will not help at all. If the C implementation is bad, 
> there's not a damn thing D can do about it, with or without 
> @system. It's always going to be this way.

And there’s not a damn thing D needs to do about bad C code. But 
D pretending all C code is safe is a disservice to users who care 
about their code being safe - and at the end of the day just 
plainly inaccurate.



More information about the Digitalmars-d mailing list