Simpler, more flexible dereferencing syntax

[bogmihdav]

Issue

In C++, dereferencing is simple in the beginning, but can become awkward pretty quickly:

val.member vs ptr->member
(***ptr).member vs (**ptr)->member
(*ptr)->method((*ptr2)->member) (e.g. pointers to wrappers with an overloaded ->)
(*(*(*ptr)->m1)->m2) (admittedly, this last example possibly goes against good OOP practice, but makes for a good showcase imo)

Proposal

Make the unary * a postfix operator instead, and in the process -> also becomes redundant. The above would become:

val.member vs ptr*.member (no need for -> anymore)
ptr***.member
ptr**.method(ptr2**.member)
ptr**.m1**.m2*

Imo, this makes both the language itself and user code simpler, makes counting the number of derefs easy, and frees up the -> for future uses.

Possible disadvantages

1. It's kinda similar (but still unambiguously different) to C++'s pointer-to-member operator. I believe pointers-to-members to be so niche, that most working C++ devs don't even know they exist.
2. C++ allows overloading ->. In Carbon's case, imo it'd make the most sense to rethink operator overloading from the ground up, rather than try to match C++ feature-by-feature.
3. Some seem to believe prefix * to be inherently more readable to a broader range of people, but I don't know & can't comment as to the reasoning behind it. Unary operators look a lot better as postfix to me personally, since they allow a more consistently pipeline-like LTR-readable syntax.
4. It breaks away from C++'s syntax. So do several other Carbon design choices however, like public-by-default class members, so I'm not too sure how much of a premium there is on keeping things familiar.

[geoffromer]

I expect this to come up for other operators besides *. For example, C++'s co_await has the same issue, and I expect Carbon to have a corresponding operator eventually (possibly more than one). For those operators, I think postfix syntax makes a lot of sense for exactly this reason.

For * it's trickier, because it will be a pretty significant familiarity issue for a lot of C++ programmers. It'll also have cascading effects on other parts of the syntax. For example, if postfix * is a dereferencing operator, it probably can't also be the operator that forms a pointer type (as in i32*). So do we use prefix * to form pointer types? That seems like it could compound the familiarity issue, and could also push us into unexplored corner cases of the parsing rules we use to disambiguate prefix, infix, and postfix *. For example, that doc points to fn F(p: Int *) -> Int * { return p; } as an example of erroneous code that's hard to recover from well. I think this change would actually fix that example, but I don't know if there are other cases that it would break.

I think some folks (notably @chandlerc) have also argued that prefix * is inherently easier to read, even for someone without a C/C++ background, but I haven't really internalized the reasoning behind that.

[bogmihdav]

Fair enough, sorry for the misread WRT Chandler's preferences. When I said "out there", I only meant it strictly within the context of C/C++ familiarity as a design goal though, i.e. that I find Carbon's other design choices to already show a not-too-low willingness to break away from traditional C/C++ syntax. It was not intended as a dismissal of other possible drawbacks

[chandlerc]

Just to clarify, my primary concern with moving to a different dereferencing syntax is with loss of familiarity.

I don't think the fact that we don't have familiarity in some places really helps argue we can lose it in even more places.

I also think that loss of expression familiarity, and an especially common and pervasive expression at that, has a much higher cost than class members.

[OlaFosheimGrostad]

You can think about giving * higher precedence than . and get value-access by:

* higher than .	* lower than .
obj.field	obj.field
*ptr.field	(*ptr).field
*(obj.ptrfield)	*obj.ptrfield
*(*ptr.ptrfield)	*(*ptr).ptrfield

Or use auto-deref: #1736

[OlaFosheimGrostad]

Also keep in mind that C++ already has a .* operator, so introducing *. would be confusing.

[etalian]

FWIW, postfix deref is something I have been using in my own programming language and like it a lot. "Unfamiliarity of syntax" was never an issue, personally (and one might argue that the better ergonomics more than make up for it). However, to make it really clear this is different syntax, I avoided repurposing * at all and use a dedicated operator (', read as prime, like a derivative in mathematics) instead. That is:
ptr->field becomes ptr'.field
*(obj.field) becomes obj.field'
*(*ptr.ptrfield) becomes ptr'.ptrfield'
As already mentioned, this also obviates the need for the -> operator altogether, removing some ambiguity with function signatures.
It sounds probably outrageous, but after all, if Carbon does not have raw-pointers, why carry over raw-pointer syntax? :)