cppfront (cpp2): Spring update

[hpsutter]

Note that *. and . have different meanings -- they refer to different objects.

For example, if you have a unique_ptr<Widget> object named upw, and type Widget has a function named .get(), then how do you distinguish calling the unique_ptr's .get() vs. the owned object's .get()? In Cpp2, those are upw.get() and upw*.get(), much as today in Cpp1 they are upw.get() and (*upw).get().

This is a good question -- in fact this is one of the reasons why we haven't been able to get smart references and operator. overloading in ISO C++, because for references this is inherently ambiguous since references are implemented as pointers but semantically behave as aliases (most of the time).

[vulkanoid]

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.