It is not possible to write a valid C++ program, where the address of a reference is the nullptr.   -----Ursprüngliche Nachricht----- Von:Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 10.02.2025 08:48 Betreff:Re: [std-proposals] Possible deprecation of -> operator An:Zhihao Yuan <zy_at_[hidden]>; std-proposals_at_[hidden]; CC:Tiago Freire <tmiguelf_at_[hidden]>; 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] <mailto: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