Re: Do we care if C compilers start allowing "." on pointers?

[Florian Weimer <fweimer@redhat.com>]

* Bill Wendling:

> On Fri, Jan 10, 2025 at 7:02 AM Paul E. McKenney <paulmck@kernel.org> wrote:
>>
>> Hello!
>>
>> Currently, given a pointer "p", C allows p->a but not p.a.  There is a
>> proposal from C++ [1] that is being considered for C.
>>
>> Do we care?
>>
> Does the proposal seem likely to be added to C++? The motivation is
> very weak, in my opinion. Other languages are very different from
> C/C++; they try to hide away memory management details, which are a
> major part of C languages. (To prevent a holy war, my comments aren't
> about the benefits and drawbacks of memory management in other
> languages.)

User-defined pointer-like types obviously have to use -> for the
deference operation because . is reserved for operations on the pointer
object itself.  So certain templated code would have to remember to use
-> anyway.  So it's surprising this proposed in the C++ context.

For C as of today, this wouldn't matter.  However, if we ever get
bounds-carrying pointers, writing p.length or p.limit to access such
information with the pointer p would make sense.

Thanks,
Florian