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