C++ seems like the language that shouldn't have this.

Posted Feb 3, 2025 21:01 UTC (Mon) by Spudd86 (subscriber, #51683)
Parent article: Quotes of the week

Honestly to me this seems far more sane in C than C++, C being a simpler language I can't think of cases where I care about the difference between p.a and p->a when writing a function past using the right one. Which just annoys me when I refactor from quick and dirty code with a struct on the stack in main to splitting it into functions that take a pointer.

C++ on the other hand because it lets you overload things so that you might have an object where you could use both operators on it and do different things allowing one in place of the other seems insane.

C++ seems like the language that shouldn't have this.

Posted Feb 3, 2025 22:28 UTC (Mon) by excors (subscriber, #95769) [Link]

I see one significant reason to care about the difference in C: it tells you whether you need to worry about null pointers. You can trivially tell that code accessing `s.x.y` is safe, but if the code is accessing `s.x->y` then you'll need to verify `s.x != NULL` (either with a test in the code, or a documented guarantee).

In the other languages mentioned in the proposal, a null dereference will give you an exception, which is just a bug. In C/C++ it's a security vulnerability, so it's pretty important to be aware of your pointer dereferencing.

Also it's a bad idea in C++ because smart pointers use `->` to access members of the pointed-at object and `.` to access members of the smart pointer itself. The proposal only changes the syntax for dereferencing raw pointers, so they would no longer match smart pointers, increasing confusion; and modern C++ should almost always be using smart pointers or references instead of raw pointers, to make ownership and lifetimes clearer, so even the proposal's hypothetical benefits wouldn't apply.

Anyway, judging by https://github.com/cplusplus/papers/issues/868 there's zero support for the idea so there's no need to worry about it.