dip1000 and preview in combine to cause extra safety errors

[mee6]

On Friday, 10 June 2022 at 03:07:23 UTC, Walter Bright wrote:
> On 6/9/2022 7:51 AM, Timon Gehr wrote:
>> Your are predicting that some people will explicitly do the 
>> wrong and lazy thing,
>
> My experience is that the vast bulk of people will do the least 
> amount of effort. It's why software is always larded up with 
> technical debt. I do it, too. Yes, sometimes I've used duct 
> tape and baling wire. Anyone who claims they haven't, I don't 
> believe :-)
>
>> hence the compiler should do the wrong and lazy thing 
>> implicitly by default. This just makes no sense. What's the 
>> big harm in annoying lazy people slightly more? It's not like 
>> they won't complain loudly about `@safe` by default in any 
>> case.
>
> I'm the recipient of all the complaints that I'm breaking their 
> existing code.
>
> > May as well do it right or not at all.
>
> This entire thread is what happens with "not at all".
>
> At some point all C functions have to be trusted in some form 
> or other because the D compiler has NO way to check them, and 
> neither does the D programmer. Putting `@trusted` on the C 
> declarations accomplishes nothing, it's safety theater.
>
> 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.

That's why it's a mistake to even mark C declarations with @safe 
or @trusted. Rust treats all C declarations as unsafe. That 
mistake could have been fixed, slightly by having C/C++ 
declarations be unsafe by default.

The word used for the keyword of @trusted is kind of wrong, C 
code should never be "trusted", it is always unsafe. So when you 
say at some point all C code is trusted, that statement is just 
wrong. Think of it as safe and unsafe. You are basically saying 
all C code is safe, when that's wrong. All C code is unsafe.