@trusted attribute should be replaced with @trusted blocks
anonymous at example.com
Thu Jan 16 00:40:12 UTC 2020
On Thursday, 16 January 2020 at 00:21:21 UTC, Joseph Rushton
> I see what you're getting at here -- you mean that if we're
> treating this function as a black box that I have no influence
> over, then both @safe and @trusted mean the same thing in terms
> of how that black box ought to behave.
> But that doesn't mean the distinction isn't useful. It gives
> me a clear indication that the code of this function (note,
> _the code of this function_, not the code of other functions it
> might call) could contain bugs that would allow memory safety
And that isn't useful to a user in any way.
> The fact that in a similar situation D forces you to annotate
> the function with `@trusted`, and alert users to the
> _possibility_ that memory safety bugs could exist within the
> code of this function, is useful information even if you can't
> access the source code.
I don't agree. @trusted doesn't alert you any more of the
possibility of a memory safety bug than @safe. You can't assume
that an @safe function won't corrupt your memory any more than
you can assume the same about an @trusted function.
> It's clearly much less useful to anyone who doesn't have access
> to the source code (which doesn't mean it's not useful at all).
(It is useless, though.)
> But in general, given the ability to read and search the
> source code (which users as well as authors can do), it's very
> useful to be able to ask the question: "Of the code in this
> project that claims to be memory safe, which bits could
> actually contain memory safety bugs?"
Yes, but you find those interesting bits by grepping over the
source code, not by looking at the attributes of public
functions. Many @safe functions have @trusted innards that don't
show up in API documentation.
More information about the Digitalmars-d