> 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.
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);
What is being proposed here is to make that code valid:
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);
That is, the naked p is still to be interpreted as what it is: a pointer. It’s just that when we write `a.b`, the language would first check the type of `a`, then dereference it as many times as necessary to get to the underlying struct, and then access its field. For instance:
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;
Now let’s see how this automatic indirection would work:
// 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);
We can still get to the actual addresses no problem:
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
Looks nifty to some perhaps, but some people really meant:
No it doesn’t. Let’s take this example in valid C:
What is being proposed here is to make that code valid: That is, the naked p is still to be interpreted as what it is: a pointer. It’s just that when we write `a.b`, the language would first check the type of `a`, then dereference it as many times as necessary to get to the underlying struct, and then access its field. For instance: Now let’s see how this automatic indirection would work: We can still get to the actual addresses no problem: Note that we can play with the & operator too. In valid C we can do this already: With automatic indirection the following would be valid too: ---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:
Looks nifty to some perhaps, but some people really meant: and forgot to write the index.