I am trying to remember why I strongly disliked the -> syntax. I certainly remember that I wasn't alone with this feeling. But, my dislike is now decades ago and I don't mind this syntax anymore.

It has certainly led me to use references instead of pointers more often, so that I can type . instead of -> . I personally think that this programming style is somewhat superior (put more things on the stack instead of the heap). So, in a way it is positive if people dislike this syntax and look for ways around it.

I guess one of the main reasons to dislike this syntax is that it is hard to type. I have been programming with both the German and the American keyboard layout and -> is not very natural to type. There is no flow between the keys and also the minus is on a key for the right pinky. This finger is much weaker and it would be preferable to not have to use it as often. I am not sure if typability is a strong argument for dropping -> . (I guess the German layout is really much worse for this. It's a good thing I have switched to the American layout a while ago.)

Given the example of Rust it shows that dropping -> altogether is not a really good idea. Rust will do the right thing most of the time if you just type a.b (even if it has to do multiple dereferences). However, there are cases where you have to be explicit about dereferencing. The only way to do this in Rust is to write (*a).b explicitly. I prefer a->b for these scenarios even if we would allow a.b for automatic dereferencing. I am not sure if it is easy to learn the cases when you must write (*a).b instead of just a.b. I guess it is much easier to teach to always use a->b when 'a' is a pointer instead of "use a.b unless the compiler complains; then use (*a).b".

On Mon, Feb 10, 2025 at 8:48 AM Tiago Freire via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

That was a lot of words to answer

“No, it doesn’t do anything for me as a programmer.”

 

Actually, I would argue that, it kind of “makes it worse”.

 

 

> But what does the syntax difference trouble me, then?

> It undermines the possible gain of making a different choice between pointers and references and overstates the cost by dividing them into two languages linguistically.

> Consider a function that takes an output parameter as a reference.

> What does it mean if you change that to a pointer? It means you want nullable and rebindable.

> What about the opposite? If the function was written in dot-only style, taking the parameter as a reference instead of pointers means removing the nullable and rebindable properties.

> If it fits your goal, then change one symbol, done deal.

 

But it’s not just “change one symbol and it is done”, is it?

 

auto copy = var; //means different things if var is a reference or a pointer

and calling

foo(var);

has to be re-written as

foo(&var);

 

And what was that about “nullable” thing?

It is not true that “references can’t be null”, they surely can, but the syntax of the language works as such that is much more difficult to make it null.

While you can just simply do:

Type* var1 = nullptr;

Type& var2 = * var1 ; // Placing something here requires more work

and requires you to do something invalid (even if in practice that dereferencing is a lie)

Should you have checked that var1 pointer before dereferencing it?

 

This has often been used as an interface contract, if it’s a pointer maybe it can be optional, if it’s a reference it absolutely isn’t optional and it better not be null.

While with a pointer you better check if it’s null, with a reference the expectation is if there’s something to check the user must have done that check before you get to the point of having a reference and any further checks can be removed as redundant since the necessary checks have already been made.

 

So, being forced to change . to a ->, or vice-versa (or any other sprinkles of * and &), when that contract changes is very convenient as it forces to revisit the code allowing you to place checks where they are needed (and previously were not made) as well as remove checks that are redundant. That helps reduce the amount of bugs introduced in this way.

 

While it might be true that if you swap a pointer with a reference (after syntactical fixes) the generated is exactly the same, the way you use it has completely changed, and it may no longer be correct code.

 

So, no! You absolutely not “just change one symbol”. Not only you still going to have to sprinkle * and &, the entire meaning and flow (and how things can an cannot fail) of everything has changed.

 

 

Since pretty much inception it was clear that there’s a fundamental difference between accessing an element of an object (.) and dereferencing a pointer and accessing an element of the dereferenced object (->). And while the operator -> itself might be redundant as you can convert var->member to (*var).member, using . to automatically dereference a pointer was never a good idea.

It’s a different thing and deserves a different symbol for it. This is not a bug or an inconvenience, It’s a feature.

 

And I’m not particularly interested in arguments about “whatever other language does” either, if I wanted that I would have use any other language.

I’m much more interested in “does C++ do it better than any other language”, and in this case the answer is yes.

 

 

 

 

So now that that’s out of the way. Again, the only thing that this proposal does is change the way you write stuff that already exists without much added benefit (to anyone).

As a general rule syntactical changes for the sake of syntactical changes are automatic rejection. Different people have different preferences, and the language shouldn’t flip flop with a tip of the hat just because you like to write things down differently.

 

This is how this proposal should have died a long time ago.

 

 

 

 

 

 

 

 

 

From: Zhihao Yuan <zy@miator.net>
Sent: Monday, February 10, 2025 4:48 AM
To: std-proposals@lists.isocpp.org
Cc: Tiago Freire <tmiguelf@hotmail.com>
Subject: Re: [std-proposals] Possible deprecation of -> operator

 

On Saturday, February 8th, 2025 at 6:57 AM, Tiago Freire via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Does the proposal improve clarity? No.

Does the proposal allows you do something new or solve a problem? No.

 

It has an opportunity to give you a different angle of

viewing a program.

 

Many believe that the unique syntax of pointers made

the unique semantics of pointers stand out. That is true

only if you believe that the semantics of pointers are

unique. But to me, there is only one semantics that sits

in the center: reference semantics. The rest are properties.

Both C++ references and pointers have reference semantics.

C++ references are non-nullable and rebindable, pointers

are nullable and rebindable, std::reference_wrapper is

non-nullable and rebindable. You can reach the same

conclusion if keep the syntax out for a moment.

 

But what does the syntax difference trouble me, then?

It undermines the possible gain of making a different choice

between pointers and references and overstates the cost

by dividing them into two languages linguistically. Consider

a function that takes an output parameter as a reference.

What does it mean if you change that to a pointer? It means

you want nullable and rebindable. What about the opposite?

If the function was written in dot-only style, taking the

parameter as a reference instead of pointers means removing

the nullable and rebindable properties. If it fits your

goal, then change one symbol, done deal.

 

Taking away the emphasis of nullable from the pointer's

use-syntax can also allow human readers to focus on important

aspects when reading some program style. For example,

 

    if (auto result = get_if(my_variant))

        use(result.x);

 

Other than "it saves me to type only 1 character instead of 2", what would I as a software developer writing C++ gain from this?

 

 

--

Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

 

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals