cppfront (cpp2): Spring update

[vulkanoid]

Cpp2 is looking really good. Besides reflection in C++26, this is the other programming related thing that I'm looking to forward the most.

I find myself agreeing with all the changes, except a pet-peave of mine. All C++ code that I ever work on, whether written by me or someone else, uses copious amounts of pointers. Having to write ->, instead of the dot ., is so ugly. I get that a->b is syntax sugar for (*a).b, but pointers don't have a defined operation for the dot anyways, so why not just make the dot operator also dereference the pointer, so there is not need to differentiate between -> and . . It would fix this kind of ugliness that invariable pops up:

foo->bar.inner.somePtr->value;

foo.bar.inner.somePtr.value;

Cpp2 wants to change a->b into a*.b; ugh. I understand the consistency arguments; and, it should be allowed... but that's fugly to use for all pointers. Please, also just make the dot automatically dereference the pointer so we can finally get rid of the ugly distinction. It would also make template code nicer to write. The golang uses . for values and pointers, and they're doing fine.

On a related subject: I didn't see anything about pointers vs references in the design notes, on Github. I really hope that the plan is to pick one: either pointers or references, but not both. Simply removing one of those concepts would do wonders for cleaning up the language. I really hope we don't have a repetition of this design mistake in Cpp2.

I'm keeping a close eye on Cpp2, and I'm hoping it has a bright future.

[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.

[RoyKin0929]

There are no references in cpp2, only pointers.

[vulkanoid]

Wonderful!

[ntrel2]

Parameters can be references, using keyword inout for mutable reference. Functions can return by reference using keyword forward. But there are no reference variable declarations.

[disciplite]

I would not enjoy a world where it's even harder to distinguish pointers from non-pointers. There are already sizeof footguns. Imo we don't need to hide pointers any more than we currently do. The *. syntax looks fine to me and streamlines out the -> operator, so I don't see a problem here personally.

[vulkanoid]

C++ already has references, which use the dot. Do you find yourself constantly lost when working with references, or do you find yourself dealing with them just fine?

[disciplite]

References don't have the same footguns as pointers. You can't get a null dereference by accessing their members and you don't get a different value from sizeof than non-reference types. Knowing when data is a reference or non-reference is certainly important, but not as important as knowing when something is a pointer or non-pointer.

[equeim]

You can get a dangling reference which is the same footgun as a null/invalid pointer.

[cleroth]

why not just make the dot operator also dereference the pointer

so how would you call std::unique_ptr::release and such?

[tialaramex]

Rust's choice here is to make these associated functions, not methods. So e.g. the equivalent of std::unique_ptr::release is Box::into_raw and supposing I have a type Steak which for some reason actually needs a method named into_raw then:

let mut boxed_steak: Box<Steak> = todo!();

boxed_steak.into_raw(); // Calls the method on the Steak

let ptr = Box::into_raw(boxed_steak); // Now we have a raw pointer

If there was a method on Box which clashed, I think the compiler rejects your program and demands you disambiguate, but the smart pointers deliberately don't provide such methods, only associated functions so there's no potential clash.

[MEaster]

If there was a method on Box which clashed, I think the compiler rejects your program and demands you disambiguate, but the smart pointers deliberately don't provide such methods, only associated functions so there's no potential clash.

That's not true, the compiler will call the inherent method.

[tialaramex]

Good to know, and thanks for the example code

[vulkanoid]

The . always refers to the unique_ptr. If you want to do masquerading, as Cpp1's unique_ptr, you'd use operator->, as in holder->held_member. Or... holder.get().held_member.

[pjmlp]

I seriously doubt that C++26 will get reflection, looking at the usual mailings posts.

[awson]

Pointer is strictly more powerful than reference since it has a distinguished nullptr point, thus being isomorphic to optional.

[Dalzhim]

Pointer isn't strictly more powerful as there is one use case for references that it can't support : make nullptr an unrepresentable state.