On Mon, Jan 18, 2010 at 9:30 AM, Steven Schveighoffer <schvei...@yahoo.com> wrote: > On Mon, 18 Jan 2010 12:12:06 -0500, Steven Schveighoffer > <schvei...@yahoo.com> wrote: > >> I think we are too late for D2, the book is pretty much finished except >> for the concurrency chapter. It is a great idea though, I would have loved >> to see this happen before D2 was released. Maybe D3 can have this change. > > I forgot one really really important requirement -- a class reference needs > to not be a general pointer. > > For example: > > Foo *foo; > foo++; // must be equivalent to foo.opInc(), not add one to the pointer. > > This may be the death knell of the idea. I don't see Walter accepting > similar syntaxes to be drastically different, and distinguishing safe D as > not using pointers is going to be a huge problem if you can't use classes.
I think one can argue it would be better for pointer arithmetic to require a more in-your-face notation, since pointer arithmetic isn't usually needed and won't even be allowed in SafeD. It isn't really standard arithmetic to begin with, since foo++ (pointer meaning) is more like foo += sizeof(Foo); Also adding pointers together is not allowed. These two things, I think, form the basis of a decent justification for making pointer arithmetic syntactically distinct from regular arithmetic. So, for instance, you could require distinct operators like *++, *+, *- for pointer manipulations. Maybe we're on to another big mistake of C here -- conflation of pointers with numbers. Or at least a corollary to the mistake of conflating of arrays with pointers. The question that then comes up is can you do overloading of those new operators? If you want to make something that is "pointer-like", then it would be necessary to do so. But probably only value-types should be allowed to act in a pointer-like manner. So you could only overload pointer arithmetic operators in a struct. But I'm not sure there's a use case for even that. --bb
