DIP 1021--Argument Ownership and Function Calls--Community Review Round 1

[Walter Bright]

On 7/18/2019 4:54 PM, Exil wrote:
> You are not limited to one example. Showing an implementation using a common 
> RAII pattern to illustrate why it isn't sufficient and why it requires a new 
> feature to replace/complement it.

One example is all that's necessary. Adding a bunch of irrelevant code to it 
adds nothing.

What part of the proposal are you not understanding?

(If one doesn't understand that simple example, a far more complex one won't help.)


>> More generally, any time there are two mutable pointers to the same memory 
>> object, one can invalidate the other. This is the principle pointed out in the 
>> "Prior Work" section. The DIP is not intended to be a tutorial on this, which 
>> is why there's a link to more explanation. It has nothing to do with RAII, and 
>> thinking about it in terms of RAII will miss the generality of the concept.
> 
> Showing an example that doesn't use malloc/free or something similar to it, 
> would be more beneficial then.

Any container that does a realloc() when something is added to it will trigger 
the problem.


> As malloc/free generally is replaced by RAII and 
> isn't/shouldn't be used directly anyways.

It's irrelevant if it is used directly or indirectly, as the result is the same. 
Since RAII is irrelevant to the issue, adding an RAII object would only serve to 
confuse the reader into thinking it is about RAII.

In fact, the DIP is not necessary if people strictly adhere to RAII.


> How does the feature differentiate between GC and non-gc allocated pointers?

It doesn't.


> If I label one function @live won't this limit all pointer operations, even though 
> it is only really relevant to non-gc pointers?

@live is a separate proposal.