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