dip1000 and preview in combine to cause extra safety errors

[Steven Schveighoffer]

On 6/13/22 6:49 PM, Walter Bright wrote:
> On 6/10/2022 5:46 AM, Steven Schveighoffer wrote:
>> I'm trying to parse this. You mean to say, there are enough unmarked 
>> extern(C) functions inside druntime, that fixing them all *as they 
>> come up* is not scalable? That seems unlikely. Note that modules like 
>> core.stdc.math has @trusted: at the top already.
> 
> It is not scalable for the reasons mentioned. Nobody has ever gone 
> through windows.d to see what to mark things as, and nobody ever will.

It's done already. Nearly all the modules have `@system:` at the top. 
The few I checked that don't are just types, no functions.

> 
> 
>> I will volunteer to mark any druntime extern(C) functions within a 
>> 2-day turnaround if they are posted on bugzilla and assigned to me. 
>> Start with @system: at the top, and mark them as the errors occur.
> 
> They aren't even done *now*, after 15+ years. See windows.d and all the 
> the others.

They are mostly marked @system, with a smattering of @safe and @trusted.

I'll tell you what, I'll do a *whole file* at a time `winsock32.d` ...

OK, I did it in less than 10 minutes.

https://github.com/dlang/druntime/pull/3839

> 
> 
>> If you think the "no-edits" bar is only cleared if extern(C) functions 
>> are assumed @safe, you are 100% wrong.
> 
> I'm not seeing how I am wrong.

```d
import core.stdc.stdio;
void main() @safe {
    printf("hello world!\n"); // fails
}
```

You are saying that nobody has any unmarked D code that uses `extern(C)` 
functions that are *already and correctly* marked @system? I'm willing 
to bet 100% breakage. Not just like 99%, but 100% (as in, a project that 
has unmarked D code, which calls `extern(C)` functions, will have at 
least one compiler error).

Unless... you plan to remark files like core.stdc.stdio as @safe? I hope 
not.

>> You can point the complaints about extern(C) functions at my ear, and 
>> deal with the significant majority of complaints that are about @safe 
>> by default D code.
> 
> That's a very nice offer, but that won't change that I get the 
> complaints and people want me to fix it, not brush it off on you.

It's trivial:

user: hey, this function in core.sys.windows.windows looks like it 
should be safe?
Walter: it's probably just that we haven't marked it yet, file a bug and 
assign it to Steve.
Me: OK, I marked it and all the related functions as @trusted (10 
minutes later)
- or -
Me: Sorry, that's not actually safe, please use a trusted escape.

There are 166 files in core/sys/windows. Each one where someone has a 
problem, I'll fix them in 10 minutes, that's 1660 minutes, or 28 hours 
of work (spread out over however long, if people find some interface 
that needs fixing). Less than a man-week. How does this not scale?

You need to learn to delegate! Especially for library functions, you 
aren't responsible for all of it!

>> I would love to see a viable safe-by-default DIP get added.
> 
> At least we can agree on that!
> 

Please, let's make it happen!

-Steve