C++ implementations are possible, where you cannot do it, because a possible runtime will catch it. Also there could be implementations, where a reference internally is not implemented as a nullable pointer.   -----Ursprüngliche Nachricht----- Von:Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 10.02.2025 10:59 Betreff:Re: [std-proposals] Possible deprecation of -> operator An:Zhihao Yuan <zy_at_[hidden]>; CC:Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden];   Here’s perhaps the most important point. Maybe I should have Highlighted that, better.     “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.”   Discussion over.     We can argue about the rest. But it overshadows the fact that it will never go anywhere regardless of any conclusions that will come out of it.   >> Type* var1 = nullptr; >> Type& var2 = * var1 ; // Placing something here requires more work > That is undefined behavior already. The rest are plain wrong. What I was trying to highlight was not so much the “assigning a null to a reference” part, but the fact that it is much harder to do so, and that you have to work at it, it is not a trivial thing to do.   But I will bite the “undefined behavior”. It doesn’t matter that it is “undefined behavior”, I can write this code all day and it will work, and there is absolutely nothing a C++ compiler can do to stop me. I can do this in less obvious and more subtle ways that goes beyond the capability of the compiler to analyze. The fact that it is bad C++ code is the point! Stop claiming that references can’t be null. They absolutely can!         From: Zhihao Yuan <zy_at_[hidden]> Sent: Monday, February 10, 2025 10:38 AM To: Tiago Freire <tmiguelf_at_[hidden]> Cc: std-proposals_at_[hidden] Subject: RE: [std-proposals] Possible deprecation of -> operator   On Sunday, February 9th, 2025 at 11:48 PM, Tiago Freire <tmiguelf_at_[hidden] <mailto: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