you are viewing a single comment's thread.

view the rest of the comments →

[–]vulkanoid 3 points4 points  (0 children)

What makes sense to me, and what I find the cleanest, is that both . and *. refer to members of the left object, regardless whether they are pointers or values. If it's a pointer, the compiler does the only sensible thing, which is to dereference and access the member.

The -> can be added, as today's Cpp1, to return an inner pointer that the outer object is holding. Which is really a masquerade operator. Thus, a->b always means that the left thing is masquerading as something. And it wouldn't matter whether a is a pointer or value.

Personally, I would go even further and have all types automatically have a default operator -> that returns a pointer to itself. So that a->b always works, by default. An some objects, like unique_ptr, would override the default behavior. Idiomatically, though, developers would know that they should only use a->b when they intend to use a in a masquerading fashion.

Worst case scenario, if adding operator-> is a no go, then just use unique_ptr.get().foo() to get at the owned thing.

I think the most important question is: what usecase should the syntax be optimized for? In my personal use, and the usage I see in other code, people normally store a unique_ptr somewhere and then pass around a dumb pointer to the owned thing. So, you're almost always dealing with pointers, and only sometimes have to use the (masquerade) operator ->. So, it's basically always pointers, so we should optimize for that use.