borrowed pointers vs ref

[Walter Bright via Digitalmars-d]

On 5/14/2014 6:09 AM, Dicebot wrote:
> 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.

I'm not suggesting unique can replace scope, I am suggesting they are separate 
concepts.


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

My comment applies when the destructor behaves as if it owns resources other 
than the object instance itself, in which case the class designer is already 
manually managing them.


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

The idea is that 'ref' are borrowed pointers, so if you're returning pointers, 
the borrowed semantics do not apply.