C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Possible deprecation of -> operator

From: Zhihao Yuan <zy_at_[hidden]>
Date: Mon, 10 Feb 2025 09:38:15 +0000
On Sunday, February 9th, 2025 at 11:48 PM, Tiago Freire <tmiguelf_at_[hidden]> wrote:

> > 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?
>

>




I'm not saying your program will compile. It will be

quite wordy to estimate the boundaries. If you want

a less involved example, then, changing a non-owning

pointer private member in a class to a reference or a

reference_wrapper. I did that a few times. If someone

in the future want to change them back to restore

nullable and/or rebindable, they may thank the

proposed change in this thread.



To give you another example, now we can use explicit

this to declare member functions,



  auto exists(this Path& self) -> bool;



where the named "self" is never a pointer. Can we

switch between the explicit this style and the traditional

style? It would be much nicer if this.member is a legal

syntax and does the right thing. (Before you argue, this

cannot be null, cannot rebind, and could have been a

reference, per Bjarne).



> 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



That is undefined behavior already. The rest are plain wrong.



>

>

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



I know somebody will say that, "fundamental difference."

And when they realized that the fact that a pointer-to-function

can be called with just fp(args) as opposed to (*fp)(args)

is exactly the counterexample - where it "loses" all the

benefits they've been voiced for, is "fundamentally different,"

and the world did not break. And they will try to find all the

exceptions around functions...



I mean, this is how people's minds work. We are influenced
by language unconsciously, and it's very hard to think outside
the box. As a Chinese user, if I'm taught I can use "he's"
or "they's", I will just accept that (Chinese is an
analytic language). The restriction where you must use
"->" to access member through a pointer but "." to access
member to access member through a reference is pretty
much a form of inflections in programming languages, which
is rare these days and fp(args) is a fairly normal example of
losing some as the language evolves.



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

Received on 2025-02-10 09:38:25