@trusted assumptions about @safe code

Paul Backus snarwin at gmail.com
Tue May 26 17:05:37 UTC 2020


On Tuesday, 26 May 2020 at 13:19:04 UTC, ag0aep6g wrote:
> I take it you guys are good with adding the note about 
> undefined behavior to the spec then? Repeating it here for 
> reference:
>
>     Undefined behavior: Calling a safe function or a trusted
>     function with unsafe values or unsafe aliasing has undefined
>     behavior.

As far as I can tell that's already implied by the first sentence 
under "safe interfaces":

> Given that it is only called with safe values and safe 
> aliasing, a function has a safe interface when:

...but being more explicit seems like it can't hurt.

The clarification I'd add would be to modify requirement #3 of 
"Safe Interfaces" to read as follows:

> 3. it cannot introduce unsafe aliasing **of memory** that is 
> accessible from other parts of the program **while that 
> aliasing exists**.




More information about the Digitalmars-d mailing list