DIP23 draft: Fixing properties redux

Jonathan M Davis jmdavisProg at gmx.com
Tue Feb 5 14:05:33 PST 2013


On Tuesday, February 05, 2013 16:53:51 Steven Schveighoffer wrote:
> On Tue, 05 Feb 2013 16:43:39 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On Tuesday, February 05, 2013 14:05:24 Steven Schveighoffer wrote:
> >> I think the point about @safe code is moot, aren't pointers disallowed
> >> in
> >> safe code anyway?
> > 
> > Goodness no. It's pointer arithmetic which is disallowed. Pointers
> > themselves
> > are perfectly safe as long as you just pass them around or dereference
> > them
> > (which would include calling functions on them). For instance, the
> > result of
> > in on an AA is a pointer to the object, and that's @safe.
> 
> Well, it would seem setting all kinds of extra rules on ref (in addition
> to the restrictions we have now), when pointers are more useful even in
> @safe code, will simply result in people using pointers more than ref.
> I'm not sure that's the right message, but I'm afraid that will be what it
> is.
> 
> For example, I have to use pointers for my linked list implementation in
> dcollections, because ref is forbidden to be used as a class or struct
> member (my nodes are structs because classes are too heavy).  Also, ref is
> not rebindable, whereas a pointer is.

That may end up happening, but the issues with ref may boil over into some of 
what happens with pointers - the key issue being escaping references. Using & 
on a local variable is already considered unsafe, but using ref as a function 
parameter gets you pretty much exactly the same thing if a local variable is 
passed to it and ref is returned by the function (I believe that discussions 
on that are what triggered Andrei's work on the DIP on ref that he brought 
up). What's really needed is to be able to detect and prevent escaping 
pointers and references, and there are a lot of difficulties with that. The easy 
way out tends to mean making a lot of code be @system, which could either end 
up being very limiting or result in a lot more code being @system instead of 
@safe. I don't know what exactly Andrei and Walter are cooking up, but SafeD 
could end up becoming very limited with regards to pointers and refs in order 
to deal with all of the corner cases.

- Jonathan M Davis


More information about the Digitalmars-d mailing list