opStar

[Bill Baxter]

0ffh wrote:
> Bill Baxter wrote:
>> Or instead of .deref you could call the property something like, oh i 
>> dunno, "opStar".  ;)
> 
> Now, there's a novel thought! ;)
> BTW might it be that this is an example how Perly syntax kluges like
> automatic dereferencing of *struct members can get you into trouble?

Or just how making special cases in general gets you in trouble.

But actually I don't think there's that much trouble here.

First, let's call it opDeref because, to quote Walter re opAdd:
"""
   The reasons for "opAdd" instead of "operator+" are:
   ...
   3) it encourages the use of operating overloading for arithmetic
   purposes, rather than "parse this predicate once", which happens with
   C++ operator overloading.
"""
http://lists.puremagic.com/pipermail/digitalmars-d/2006-October/009478.html


Second, the only thing that makes sense if you're going to have smart 
pointers is to make them act in every way possible like regular 
pointers.  Iterators are just the underevolved Neanderthal ancestors of 
smart pointers, but they're still smart pointers of a sort.

So we have to make "x.member" call "x.opDeref.member" if x is something 
with an opDeref.

Third: we need to figure out some way to actually get at x's own members.

I think there are a number of ways you could do that.

1) In D, the magic pointer dereferencing will only dereference one 
level.  So that means if x is a struct with opDeref, then (&x).member 
will give you a member of x itself, not of the opDeref.

2) Make a special property that if used disables the opDeref.  Maybe 
even x.this.member could be used for that.  Actually, I think because of 
1) that should work automatically if x is a struct.

3) Introduce an alternate member access syntax for 'raw' member access. 
  Like x:member, x::member, x->member,  x..member.


Option 1) seems the most reasonable to start with, since it shouldn't 
actually require doing anything.

--bb