C++ Logo

std-proposals

Advanced search

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

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Sat, 8 Feb 2025 15:33:25 +0100
It was not an argument for getting rid of ->, but that some known young languages still have explicit dereferencing to distinguish between pointer and pointee when accessing.   -----Ursprüngliche Nachricht----- Von:Jonathan Wakely <cxx_at_[hidden]> Gesendet:Sa 08.02.2025 14:34 Betreff:Re: [std-proposals] Possible deprecation of -> operator An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>;   On Sat, 8 Feb 2025 at 13:22, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: Go and Rust use * for dereferencing.   https://go.dev/tour/moretypes/1  Even though there is no pointer arithmetic, and therefore no chance of misunderstanding what `p + 2` means, it looks like you still need to say `*p + 2`, i.e. no implicit dereferencing of pointers to act on the pointee.   https://doc.rust-lang.org/book/appendix-02-operators.html   Rust uses (*p). to access members of pointed to objects in unsafe mode.  Again, no implicit dereferencing. It looks like you need to use `(*p).i` rather than just `p.i` to access a member through a pointer.  So while it's true that they don't have -> for dereferencing pointers, they are not arguments in favour of using . to dereference pointers. You could use them as arguments for getting rid of -> because we can just do `(*p).i` instead, but I don't think anybody wants that!

Received on 2025-02-08 14:37:26