opStar

[0ffh]

Bill Baxter wrote:
> Well, Janice's point still stands.  If that were a real justification 
> then we should be jumping up and down about the fact that ptr.sizeof 
> returns 4 instead of the size of the thing it points to.

IMHO it's not quite the same. Usually you wouldn't create structs with
a member called "sizeof", whereas a member called "val" or "value" is
a rather common beast. I admit this could be circumvented by using a
less common property name like "deref", but that was not my point.
What I sighed about was the apparent lack of reading before ranting.

> Walter should just address the real issue.  Are smart pointers in D 
> really going to require (*p).member?  Or is there something else in the 
> works for transparent overriding of member access?

Believe me, I am also not happy about "(*p).member". I wonder if getting
back -> for that purpose (as has been suggested) might be viable. Would
make "p->member". Or maybe "p.deref.member" if you need, but please not
"p.value.member", I think that might break a lot of code.

Regards, Frank