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_at_[hidden]> 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_at_[hidden]>
> *Sent:* Monday, February 10, 2025 4:48 AM
> *To:* std-proposals_at_[hidden]
> *Cc:* Tiago Freire <tmiguelf_at_[hidden]>
> *Subject:* Re: [std-proposals] Possible deprecation of -> operator
>
>
>
> On Saturday, February 8th, 2025 at 6:57 AM, Tiago Freire via Std-Proposals
> <std-proposals_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>