Hello,
I have to say I would not much be in favor to have that feature in C,
usually people try to make the fact that something is a pointer very
visible in C.
By indicating 'p' on the member/variable names perhaps? after 30 years in C, and 5 in JS, I really find that the idea that a thing is a pointer vs an instance of a thing is only a detail that the language MAKES the developer be aware of. In reality, the programmer just wants to get the value of a member from an object; and whether that object is statically defined or pointed to by a variable is really fairly inconsesquential.
It only took MS until 2015 to implement C99; it'll be a whole generation before this could really catch on.
But then also:
> C++ Standard section 8.5.1.5 Class member access
> add:
> if the first expression of (dot) is a pointer [to an object], then
> E1.E2 is converted to (*(E1)).E2 .
Doing like this would certainly be the wrong way for C.
I split the gists
The C standard just words it as
--- standard quotes
6.5.2.3 Structure and union members
constaints
1) The first operand of the . operator shall have a qualified or unqualified structure or union
type, and the second operand shall name a member of that type
2) The first operand of the -> operator shall have type ‘‘pointer to qualified or unqualified
structure’’ or ‘‘pointer to qualified or unqualified union’’, and the second operand shall
name a member of the type pointed to.
semantics
4)
A postfix expression followed by the -> operator and an identifier designates a member
of a structure or union object. The value is that of the named member of the object to
which the first expression points, and is an lvalue.83) If the first expression is a pointer to
a qualified type, the result has the so-qualified version of the type of the designated
member.
16) (cut, about flexible array member) ... However, when a . (or ->) operator has a left operand that is
(a pointer to) a structure with a flexible array member and the right operand names that
member, it behaves as if that member were replaced with the longest array (with the same
element type) th ...
83) If &E is a valid pointer expression (where & is the ‘‘address-of ’’ operator, which generates a pointer to
its operand), the expression (&E)->MOS is the same as E.MOS.
--- end quoting
so, the intent appears to make everything behave like -> in the C standard?
E.MOS into (&E)->MOS
whereas the working in the C++ standard makes everything behave like '.' . E1->E2 into (*E1).E2
There isn't really a whole lot of definition about how to implement the above; and the -> operator appears very few times in the C standard...
The two operations `E1->E2` look very similar `(*(E1)).E2` but are not
the same, in particular when evaluated in a thread context. The first
is an lvalue that is guaranteed to only access the member, where the
second forms the `*E1` object as a whole, and so may race with
accesses to other members of the same object.
Except, they are both 'get the member E2 from E1' , which really makes them entirely the same.
A thread context... this doesn't change anything about volatile members... And there's nothing that -> or '.' themselves helps or clarifies with threads... in either case they are either referencing a volatile instance, or volatile member, or volatile pointer to a thing with volatile members, the proposed modification doesn't change the characteristics of access at all.
Given thread local declaration which could either be a struct or a pointer, I don't see how either operator makes thread access apparently more or less safe; like if I was reading threaded code and saw '->' why would that make me feel any better about shared access than '.' ?
I might again stress, in a different way, it's about the member in the object, not the whole object.