Simplification of @trusted

[Paulo Pinto]

On Thursday, 17 June 2021 at 12:14:18 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 17 June 2021 at 11:51:03 UTC, Paulo Pinto wrote:
>> Actually that is the same road taken by Rust, all interop with 
>> C libraries is considered unsafe.
>
> The big difference is that Rust _has_ language level unique 
> ownership and a full blown borrow checker. So in that case the 
> lexer can take over ownership and be certain that the 
> filebuffer is fully isolated.
>
> If D wants to compete it has to be more pragmatic.
>
> Anyway, it doesn't really matter what language lawyers say. 
> People _will_ use `@trusted` in their system-level code bases 
> as they see fit in order to get pragmatic safety, meaning not 
> loosing out on efficiency and still get more checks than making 
> everything `@system`.
>
> This is inevitable.
>
> Programmers care about what is best for _their project_, not 
> what some goofy idealistic people claim on a philosophical 
> level.
>
> This includes game-oriented libraries. So there will never be 
> an eco-system where `@trusted` has the semantics language 
> lawyers claim that they should have. Therefore it is fatally 
> flawed to make that requirement in the first place.
>
> It is a tool, not a religion. People are not afraid of going to 
> `@safe` hell. If your only alternative is `@system`, then there 
> is no reason for programmers to not abuse `@safe` and 
> `@trusted`.
>
> Appealing to religion won't work.

Which is why on some deployment platforms where security is the 
top selling point for their customers, like 
https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products, require admin access to enable a tainted binary (e.g. unsafe code) to be made executable.

Developers point of view doesn't matter for security assessments.