opStar

[Bill Baxter]

Michel Fortin wrote:
> On 2007-11-10 09:27:30 -0500, "Janice Caron" <caron800 at googlemail.com> 
> said:
> 
>>> Smart pointers will have to be done a different (and hopefully better)
>>> way in D.
>>
>> Well here's to that. Looking forward to finding out what it is.
> 
>    a.opStar.b
> 
> But seriously, operator overloading's goal is to allow the programmer to 
> use a consistent syntax for native and non-native types. 

I think that's an excellent point.  If you have to use unnatural syntax 
to use it (i.e. (*x).member) then you might as well make it a normal 
member property.   I'd much rather have x.val.member all over my code 
than (*x).member, and in fact that's the way I've translated the 
operator* in all the iterators i've ported from C++ to D.

Granted, having opStar/opDeref would make at least some syntaxes work 
for both pointers and smart pointers, but it would really suck if all 
code for handling iterators generically (like a std.algorithm module) 
were forced to use that cumbersome syntax in order to be generic.  D has 
been striving for some time to make writing templates as simple and 
straightforward as possible.

It almost seems to me that if (*x).member and x.member are going to have 
different meanings, then x.member should be the one that gets overridden 
by opStar.  Except that it makes no sense if you deconstruct it because 
of the order of evaluation forced by the parentheses.  So maybe there 
needs to be a completely different way to do the operation of "I want to 
dereference the raw POINTER darnit! then access a member".  If you don't 
use that special one then what you get would be opStar's version.

--bb