borrowed pointers vs ref

Dicebot via Digitalmars-d digitalmars-d at puremagic.com
Wed May 14 06:09:25 PDT 2014


On Tuesday, 13 May 2014 at 20:46:19 UTC, Walter Bright wrote:
> On 5/13/2014 12:06 PM, Dicebot wrote:
>> No, it still can be necessary. `scope` can greatly help not 
>> only with resource
>> releasing, it is also missing tool to safely cast from shared. 
>> Locking shared
>> variable can return same variable casted to scope qualifier 
>> which will
>> guarantee  that no reference has been stored to shared object 
>> by the time lock
>> is released.
>
> I believe that is the role of `unique`. DIP69 addresses making 
> unique pointers in D, and there have been several PR's 
> implementing aspects of it.

I don't really understand how you see this working. Sure, unique 
concept from that DIP can somewhat replace `scope` storage class. 
But you can't prove that some function does not leak unique 
variable internals if this is not annotated as such.

>> And "if those are marked as refcounted" as assumption is no 
>> better than "if
>> those are owned by GC" ;)
>
> I think that an object that wants to completely own its 
> resources must properly encapsulate and restrict unsafe access 
> to them itself.

This statement is not much different from "any programmer who 
cares about memory should manage it manually" or "instead of 
const qualifier you can simply use convention". Doing this 
without compiler help is tedious. Mistakes result in bugs that 
are insanely hard to debug (storing non-shared reference to 
shared object by an accident).

>> Also A can only control escaping of any internal references 
>> only by completely
>> prohibiting access to it which is not good. You have no means 
>> to say "feel free
>> to use this reference as long as you don't keep it outside of 
>> current scope".
>> And you effectively say "make all your array members private 
>> to keep borrowing
>> guarantees".
>
> You can by only returning ref's.

Also slices and pointers (or structs with pointers inside).


More information about the Digitalmars-d mailing list