dip1000 and preview in combine to cause extra safety errors

[Steven Schveighoffer]

On 6/10/22 1:14 AM, Walter Bright wrote:
> On 6/9/2022 8:49 PM, Steven Schveighoffer wrote:
>>> In druntime, we've gone through many (certainly not all) of the C 
>>> declarations and appropriately added correct annotations to them. But 
>>> realistically, this is not scalable.
>>
>> I am completely lost here. How is it not scalable to go into every 
>> libc module of druntime and mark them with `@system:` at the top? I 
>> can do it if you want, it probably will take 10 minutes. Most time 
>> will be spent searching for already existing @system: attributes to 
>> skip having to attribute that module.
> 
> I did say "correct annotations". Granted, just slapping @system on them 
> is easier.

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.

My point above is that unmarked extern(C) calls are @system now, and 
marking them as @system will not change anything.

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.

> 
> My experience is that asking people to make *any* edits to existing 
> files is asking a lot, especially if it is code that is considered 
> tested and working, and especially if it is code they don't have rights 
> to the repository to change.
> 
> I'm the one who gets the earful when these changes are needed.

The vast majority of compiler errors that will come from a 
safe-by-default DIP are functions that are actually @system and now 
implicitly get marked @safe -- not because they call unmarked extern(C) 
functions, but because they do @system things (like casting). If you 
think the "no-edits" bar is only cleared if extern(C) functions are 
assumed @safe, you are 100% wrong.

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.

I would love to see a viable safe-by-default DIP get added.

-Steve