@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