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 
> 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.


More information about the Digitalmars-d mailing list