DIP 1021--Argument Ownership and Function Calls--Final Review

[Walter Bright]

On 9/19/2019 5:43 AM, Olivier FAURE wrote:
> 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.

I've been looking into making the DMD source code @safe. Because of all the 
interconnected dependencies, it's looking like the only way is to make 
everything @trusted, and then piece by piece make it @safe.

Because DMD does lazy semantic analysis (for very good reasons), going const has 
been a frustrating experience and is unlikely to ever happen.


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

Yes, but code must have a transition path. DMD would still be in C++ if I 
couldn't translate it function by function, keeping the entire codebase working 
and passing the test suite at each step. I did a number of ugly things to make 
it happen - but now that it's in D I gradually go back and fix the compromises.

It's like how the first intercontinental railroad was built. It was all 
quick-and-dirty, slap dash, unsafe, and ramshackle. It was also built entirely 
with muscle. But once it was done, and trains could be run on it, suddenly it 
was incredibly useful, money was coming in, etc., and piece by piece the crappy 
construction was fixed. It could not have been built otherwise.


> 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

Is there a language that uses this, or is it entirely new?