I mean technically the compiler could just have been less stupid and made `.` auto-deref, it’s not like C has operator overloading so the LHS is either a struct or a pointer, not both.
It is frequent to have multiple "*", "[]", "." and "->".
Now you have the simple rule of executing first the postfix operators from left to right, then the prefix operators from right to left.
If some special rules had to be invented to avoid writing the parentheses in "(*x).y", after adding several "*", "[]" and "." it would become impossible to understand the right evaluation order.
When all of "*", "[]" and "." are postfix, they are just executed in order from left to right, which is easy to understand.
While sometimes auto-dereferencing a pointer would be convenient, in C you want frequently to get the value of a link, or to do pointer arithmetic. With auto-dereferencing, some new ways of using an "address of" operator would have to be invented, which are unlikely to be more simple than the current rules.
Like I have said, the 2 languages that have introduced the concept of pointers were Euler, with explicit dereferencing, and CPL, with implicit auto-dereferencing.
Both are valid ways to design a programming language, but in both case a lot of rules must be added to cover all the use cases, which would have to be more complex in the languages with auto-dereferencing, so these languages usually solve this problem lazily, by just prohibiting some uses, e.g. by prohibiting pointer arithmetic.
As I have written above, a language with implicit dereferencing needs additional syntactic means for denoting the cases when the values of the pointers are needed, e.g. for doing pointer arithmetic, which is frequent in C.
If dereferencing would have been made implicit, that would have required a large number of changes in the language. C++ has introduced pointers with implicit dereferencing, i.e. what C++ calls references, but due to the fact that the other syntax changes that are needed have not been made, because they would break compatibility, the C++ references can replace C pointers only in a subset of their uses.
You're misunderstanding the comment. They aren't asking for implicit derefs. They're asking for explicit derefs, using * or . instead of * or ->
Which is ironic when discussing overloading!
Excuse my confusion, this possibility didn't occur to me.
And I think escaping emphasis was only introduced somewhat recently? I do remember that for the longest time you basically had to trick HN into not breaking your comments by using a different character in stead.
*
(Up-thread I think it probably was like that when they commented, but has since been fixed.)
> "a.b" should be enough for pointers as well,
I have interpreted this to mean implicit deref, as there is no "*" (could be a formatting problem).
The proposal is literally: "If you see . and the left operand is a pointer, pretend the . was -> instead, because otherwise the code is already invalid."
However, I assume that this would have been a too complex solution for compilers that had to work in a few tens of kilobytes of memory, while a postfix "*", as already used a decade before C, would have been a trivial solution.
It's literally the same complexity as the type checking compilers already do to tell you that your `.` does not work because the LHS is a pointer not a struct.
To determine if implicit dereferencing may be applied, more analysis has to be done, because there it may be not only a pointer to a structure, but a pointer to a pointer to a structure and so on, so multiple implicit dereferencing may be needed to obtain a valid expression.
However I agree that the difference in complexity is not big.
And no, this would not perform multiple levels of dereferencing anymore than -> does today. You could have literally find&replaced every use of -> with . and every C program would have had the exact same semantics. `struct point **a; a.x = 1` would throw the exact same compilation error that `struct point **a; a->x = 1` throws today. The only difference would be that `struct point *a; a.x = 1;` would write 1 to the field x of the object pointed to by a, instead of throwing an error that says "object of type struct point* has no field named x".
No it doesn’t. Let’s take this example in valid C:
struct my_struct { int field };
struct my_struct s = { .field = 42 };
struct my_struct *p = &s;
printf("direct : %d", s.field);
printf("pointer: %d", p->field);
printf("address: %x", p);
struct my_struct { int field };
struct my_struct s = { .field = 42 };
struct my_struct *p = &s;
printf("direct : %d", s.field);
printf("pointer: %d", p.field); // note the use of a dot here
printf("address: %x", p);
struct my_struct { int field };
struct my_struct s = { .field = 42 };
struct my_struct *p = &s;
struct my_struct **pp = &p;
struct my_struct ***ppp = &pp;
// All would print the same value
printf("%d", ppp.field);
printf("%d", pp .field);
printf("%d", p .field);
printf("%d", s .field);
// We can still use explicit indirections
printf("%d", (*ppp ).field);
printf("%d", (**ppp ).field);
printf("%d", (***ppp).field);
printf("%d", (*pp ).field);
printf("%d", (**pp ).field);
printf("%d", (*p ).field);
printf("p: %x", p);
printf("p: %x", *pp);
printf("p: %x", **ppp);
printf("pp: %x", pp);
printf("pp: %x", *ppp);
printf("ppp: %x", ppp);
printf("s.field: %d", s.field);
printf("s.field: %d", (*&s).field);
printf("s.field: %d", (**&&s).field);
printf("s.field: %d", (***&&&s).field);
printf("s.field: %d", (&s).field);
printf("s.field: %d", (&&s).field);
printf("s.field: %d", (&&&s).field);
The kicker here is that the decision on whether an access to a struct member requires dereferencing the pointer or not, is not done at parsing time. It’s done at type checking time. And by the way, in standard C the decision to give you an error or not is already done at type checking time. All this to say, this would be a fairly benign change to compilers.
Now would users get confused? Possibly. With the conflation of pointers and arrays, the following would be equivalent:
array.field
(*array).field
array[0].field
array[i].field
Since in all situations where pointer->field is valid pointer.valid is an explicit error in C today, this would have been very much doable without major changes in compiler or language implementation.
Of course, at C's level of abstraction, and given the speed limitations of the day, the syntax difference between -> and . may well be argued to have been helpful instead of harmful.
And yes, the same could not be said for C++, where you can implement dereferencing for your own type and get a variable where both `a.b` and `a->b` are valid and have different meanings. This is anyway not a proposal for changing C (or C++) today, merely a "what if" discussion about how C could have been designed differently.
x = a->b->c->d->e;
x = a.b.c.d.e;
x = a.b.c->d.e;
PS: ...and of course C++ messed this simple rule up with the introduction of references.
That's why I would have used a postfix @ for dereferencing.
I’ll entertain this when C fixes (or at least removes) integer promotion, which is a source of far more bugs and misunderstandings than this could ever be: `.` auto-deref-ing does not actively undermine what little type system C has.
You assert that you do not want this on grounds of clarity. It is not an unrelated problem to point out that C has numerous obscurity issues significantly worse than this could ever be in the language right now.
> Implicit operator overload is just a bad design.
That's at best a bunch of words arranged nonsensically, and at worst an assertion that you want to remove arithmetic operators from the language?
> Integer promotion has advantages and disadvantages, especially in a language like C where you often use 8bit or 16bit types for memory optimization/alignment reasons.
It's mostly a major actual source of obscurity and bugs.
1)Implicit operator overload is a bad design in case of pointers and objects because a.b and a->b are both readable, easy to type and short.
2)Integer promotion is not as simple because requiring explicit promotion makes a holy unreadable mess out of your code in the simplest of cases.
2) is demonstrated many times by mongo code lines in Java with all the explicit casts. This is also the reason Python has implicit promotion for its number type. You sacrifice something to get something unlike in 1) where you only lose for no gain what so over.
You're just not being honest.
> 1)Implicit operator overload is a bad design in case of pointers and objects because a.b and a->b are both readable, easy to type and short.
That's just a baseless assertion. Here I can do the same: implicit overloading is a great design in case of pointers and objects because a.b is always unambiguous and uniform, and -> is a harder to read and type extra operator which has no justification.
And then obviously your assertion can be used exactly the same way to similarly assert that every numeric type should have its own set of arithmetic operators, after all u4+ is also readable, easy to type, and short.
> 2)Integer promotion is not as simple because requiring explicit promotion makes a holy unreadable mess out of your code in the simplest of cases.
Integer promotion is much simpler because it's literally a never-ending source of bugs.
> This is also the reason Python has implicit promotion for its number type.
Python does not have implicit promotion for its number type, at best Python 2 had that for performance reasons (definitely not "mongo code lines with all the explicit casts" which it could not care less about), and in reality that was not even the case because it does not corrupt your data upfront as C does.
Oh let me assure you, I have no actual expectation that C would ever change in such a way.
Although it should be noted that both suggestions are entirely syntactic and could be gated behind a per-file (or even per function) stricture a la strict mode.