Re: Is it time to remove INTERNAL_FIELD?

[Eli Zaretskii <eliz@gnu.org>]

> From: Oleh Krehel <ohwoeowho@gmail.com>
> Cc: monnier@IRO.UMontreal.CA,  emacs-devel@gnu.org
> Date: Thu, 23 Apr 2015 16:07:39 +0200
> 
> > What this macro does is allow you to use field names like 'foo', when
> > the field is really called 'foo_'.
> >
> > I think it's okay to remove INTERNAL_FIELD, but I think we should keep
> > the trailing underscore appended in BVAR and KVAR.
> [...]
> I'm totally fine with this:
> 
>     INLINE void
>     kset_last_kbd_macro (struct kboard *kb, Lisp_Object val)
>     {
>       kb->Vlast_kbd_macro_ = val;
>     }
> 
> just as I'm fine with this:
> 
>     INLINE void
>     kset_last_kbd_macro (struct kboard *kb, Lisp_Object val)
>     {
>       kb->Vlast_kbd_macro = val;
>     }

We are talking past each other.  I wasn't talking about
kset_last_kbd_macro etc, I was talking about expressions that
explicitly mention field names.  Like this one:

  foo->name = bar;

or this:

  BVAR (foo, name) = bar;

or this:

  buffer_name = BVAR (foo, name);

It's the "name" part that I care about.

If "BVAR (foo, name)" expands into "foo->name_", then no code can use
bar->name anywhere without triggering a compilation error.  But I, as
code write, can still call the field "name" and use it in my code, and
have the preprocessor append the underscore for me.

> It's not obvious how simple or intricate INTERNAL_FIELD is or what it
> does. At the first glance, looks like C++ member function call.

And what's wrong with that?  For someone who programs in C++, and
should therefore be ready to accept overloaded operators that can
compute the end of the world as part of their processing, how do you
know, in C++, that "->" is not overloaded to do just that?