DIP77 - Fix unsafe RC pass by 'ref'

[Walter Bright via Digitalmars-d]

On 4/10/2015 7:23 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>" wrote:
> On Wednesday, 8 April 2015 at 23:11:08 UTC, Walter Bright wrote:
>> http://wiki.dlang.org/DIP77
>
> In general, this is way too much focused on reference counting. The DIP does
> define "RCO" in more general terms, but still, it feels like the wrong approach.
>
> You also seem to look at Rust's type system from the same POV ("only one mutable
> reference at a time, for efficiency"), but that's not the point at all: it's
> about safety in general, not efficiency for RC. It encompasses so much more:
> memory safety, race-free sharing of data, avoiding iterator invalidation...
> DIP77 cannot help with general iterator invalidation at all.

D uses ranges, not iterators.


> Another thing that just feels wrong is the automagic copying. We're passing
> something by `ref`, and the compiler inserts a copy behind our back?! And this
> isn't even visible to the user...
>
> Because the topic is correctness, @safe/@system seems the correct way to
> approach the problem. The compiler should just treat unsafe pass-by-ref as
> @system, as Martin suggests. Basically, instead of inserting a copy, pass-by-ref
> will be @system, when no copy would need to be inserted, it will be @safe.

A difficulty with that is the semantics will change as the compiler improves and 
gets better at realizing no copy would be needed. Having the @safety be 
"implementation defined" would be unhappy.


> I also think that the unsafety detection heuristic is too simplistic. When
> scope/return is extended to pointers and other kinds of references, there would
> probably be way too many false positives. A more sophisticated analysis is
> necessary that can more realistically determine when mutable aliasing can occur.
> E.g., it can also take uniqueness into account.
>
> Besides, the address and slice operators also need to be taken into account, and
> these can appear outside of function calls.

I expect any use of RCO's necessarily means the implementation of the RCO is 
unsafe (after all, it calls free()), but a safe interface is provided. The safe 
interface to an RCO is tightly controlled with 'return ref'.