On Tuesday, February 05, 2013 16:53:51 Steven Schveighoffer wrote: > On Tue, 05 Feb 2013 16:43:39 -0500, Jonathan M Davis <[email protected]> > > 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
