DIP 1021--Argument Ownership and Function Calls--Final Review
Olivier FAURE
couteaubleu at gmail.com
Thu Sep 19 12:43:21 UTC 2019
On Thursday, 19 September 2019 at 09:42:06 UTC, Walter Bright
wrote:
> D's transitive const has also proved difficult to retrofit into
> existing code (like the DMD source code).
> That's right, it won't be. Just like if you call an @trusted
> function from an @safe one, it won't be safe, either (at least
> the compiler can't check it for you).
I think those two comparisons are interesting, because @trusted
and const have different semantics, as far incrementally fitting
them goes.
const (and @pure) starts from the "leaves", the small functions
that don't call anything else. As your refactoring progresses,
more and more functions become pure, closer to the root, until
ideally everything but your main() is pure.
@trusted, on the other hand, is something you're trying to get
rid of. You really, really don't want a codebase where half your
code is marked as @trusted, because that means half your code
needs to be audited to find any potential memory vulnerability.
The way you've described @live, it would be something between the
two. Like, it's an attribute you add to functions that you
incrementally convert to the new paradigm; but it's also
something you really don't want half your code to have, because
then you need to manually audit every non- at live code interacting
with @live code to make sure memory corruption doesn't happen.
Not sure if I'm explaining this clearly.
> > https://gist.github.com/PoignardAzur/9896ddb17b9f6d6f3d0fa5e6fe1a7088
>
> I haven't studied that. Is it a 100% solution? I know there's
> one being worked on for C++, but it's an 80-90% solution.
It's 100% memory-safe, transitive, mechanically checkable,
malicious-non- at trusted-code proof.
I've been trying to nail down the semantics, and I think[1] it
requires lifetime annotations (I need to take the time to write a
demonstration why at some point), but that's nothing that
wouldn't apply to the @live proposal as well.
[1]
https://forum.dlang.org/thread/qssaruktegnbtsdjeyri@forum.dlang.org
More information about the Digitalmars-d
mailing list