dip1000 and preview in combine to cause extra safety errors

Timon Gehr timon.gehr at gmx.ch
Thu Jun 9 12:58:18 UTC 2022


On 09.06.22 08:46, Walter Bright wrote:
> On 6/8/2022 5:38 PM, Timon Gehr wrote:
>> This does not have anything to do with `@safe` by default, it's just 
>> an inconsistency in the compiler implementation.
> 
> I could make a case for every one of the safety checks being checked in 
> @system code, too.
> ...

No. You really would not be able to. The point of `@safe` is to catch 
everything that's bad. The point of `@system` is to allow everything 
that makes sense.

If the compiler can't figure out if something is fine, it should be an 
error in `@safe` code and allowed in `@system`.

But if the compiler can easily tell that something makes no sense, it 
should still be an error in both `@safe` and `@system` code!

> The existing checks you note were there long before 
> @safe/@trusted/@system was added. Them remaining is an artifact of 
> evolution and a wish to support legacy behavior.

It's a pity you feel this way. Clearly if something is _always wrong_ it 
makes sense to have a diagnostic. There is type checking in `@system` 
code, and that makes sense. E.g., we don't just make accessing an 
undefined identifier in `@system` code UB, because that would be ridiculous.


More information about the Digitalmars-d mailing list