How about always using -> in those cases? Never use the object directly and C++ references, but always use pointers and smart pointers?   -----Ursprüngliche Nachricht----- Von:Zhihao Yuan via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 10.02.2025 10:38 Betreff:Re: [std-proposals] Possible deprecation of -> operator Anlage:signature.asc An:Tiago Freire <tmiguelf_at_[hidden]>; CC:Zhihao Yuan <zy_at_[hidden]>; std-proposals_at_[hidden];     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. _______________________________________________ -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals