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