DIP1028 - Rationale for accepting as is

Zoadian no at no.no
Wed May 27 21:12:12 UTC 2020


On Wednesday, 27 May 2020 at 13:47:46 UTC, Claude wrote:
> On Wednesday, 27 May 2020 at 13:42:08 UTC, Andrej Mitrovic 
> wrote:
>> Is the actual problem those `@trusted:` declarations at the 
>> top of C headers?
>>
>> There could be a simple solution to that:
>>
>> Ban `@trusted:` and `@trusted { }` which apply to multiple 
>> symbols. Only allow `@trusted` to apply to a single symbol. For
>
> IMO, it makes things worse. Because the careless programmer 
> will slap @trusted to every declaration (maybe with a script or 
> find/replace macro of his editor). So now, we don't know if the 
> annotation is greenwashing or careful examination of the 
> definition.
>
> At least with "@trusted:" and "@trusted { }", the greenwashing 
> is obvious.

the problem here ist: we are talking about careless programmers.
for those of us who actually care about safety it will be like:
1. ok lets write an extern(c) function.
2. forget to annotate it by accident.
3. hit compile
4. a) get an compiler error the hints that we missed that 
annotation
or b) no error at all and we now have silently added unsafe code 
to our codebase.

also, you can never trust that an @trusted function is actually 
memory safe.
even if it was evaluated in the past. the addition of new code 
(and even completely @safe code) can break any assumptions that 
@trusted fun was relying on.

so a competent QA team _has_ to either check all @trusted code 
fragments.
or with this dip check all @trusted and all extern functions.


More information about the Digitalmars-d-announce mailing list