5 ms·

> Otherwise "(x).y" would have been needed, instead of "x->y". With a postfix "", that would have been "x*.y", and "->", would not have been needed. I mean t

> Otherwise "(*x).y" would have been needed, instead of "x->y". With a postfix "*", that would have been "x*.y", and "->", would not have been needed. 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.

adrian_b 3y ago
It is not that simple, because in C you may chain a great number of prefix and postfix operators. 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.
- renox 3y ago
  The problem with postfix * for dereferencing is that it would look like a multiplication.. That's why I would have used a postfix @ for dereferencing.
- tsimionescu 3y ago
  I believe GP means that "a.b" should be enough for pointers as well, you don't need "a->b" or "(*a).b". It's not like pointers can have fields in C, so the meaning would have been unambiguous.
  - adrian_b 3y ago
    Sorry, I had posted a partial reply before finishing writing the complete one. 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.
    - dataflow 3y ago
      > If dereferencing would have been made implicit You're misunderstanding the comment. They aren't asking for implicit derefs. They're asking for explicit derefs, using * or . instead of * or ->
      - psd1 3y ago
        Your and GP's make no sense unless the reader knows that * is a markdown directive and infers where you typed them. Which is ironic when discussing overloading!
        dataflow 3y ago
        In confused, where in my comment does the Markdown syntax come into play? You're not seeing italics or backslashes are you?
        3y ago
bluecalm 3y ago
There is something to "explicit is better than implicit" mantra. I appreciate the C way because if I write a.b and it's an error it clarifies what's going on in my head (I now know a is a pointer not an object).
- masklinn 3y ago
  > There is something to "explicit is better than implicit" mantra. 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.
  - bluecalm 3y ago
    Man, this is completely unrelated problem. Implicit operator overload is just a bad design. 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.
    - masklinn 3y ago
      > Man, this is completely unrelated problem. 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.
      - bluecalm 3y ago
        You are not arguing in good faith but just in case I will point out what you are missing: 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.
hknapp 3y ago
https://stackoverflow.com/questions/13366083/why-does-the-arrow-operator-in-c-exist https://stackoverflow.com/questions/13366083/why-does-the-ar...
atilaneves 3y ago
Proof of the fact that this works is that D does exactly this.
- masklinn 3y ago
  AFAIK it works like that in most modern languages with pointers: Rust, Zig, even Go will implicitly deref pointers on attribute access.
Snarwin 3y ago
Interestingly, C already does this for function calls: "fptr()" is considered equivalent to "(*fptr)()".
- kps 3y ago
  A mistake, IMO; I want to be able to see right away whether a call target is static or dynamic.

> Otherwise "(*x).y" would have been needed, instead of "x->y". With a postfix "*", that would have been "x*.y", and "->", would not have been needed. I mean t

adrian_b 3y ago

It is not that simple, because in C you may chain a great number of prefix and postfix operators. 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.

renox 3y ago
The problem with postfix * for dereferencing is that it would look like a multiplication.. That's why I would have used a postfix @ for dereferencing.
tsimionescu 3y ago
I believe GP means that "a.b" should be enough for pointers as well, you don't need "a->b" or "(*a).b". It's not like pointers can have fields in C, so the meaning would have been unambiguous.
- adrian_b 3y ago
  Sorry, I had posted a partial reply before finishing writing the complete one. 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.
  - dataflow 3y ago
    > If dereferencing would have been made implicit You're misunderstanding the comment. They aren't asking for implicit derefs. They're asking for explicit derefs, using * or . instead of * or ->
    - psd1 3y ago
      Your and GP's make no sense unless the reader knows that * is a markdown directive and infers where you typed them. Which is ironic when discussing overloading!
      - dataflow 3y ago
        In confused, where in my comment does the Markdown syntax come into play? You're not seeing italics or backslashes are you?
        3y ago

bluecalm 3y ago

There is something to "explicit is better than implicit" mantra. I appreciate the C way because if I write a.b and it's an error it clarifies what's going on in my head (I now know a is a pointer not an object).

masklinn 3y ago
> There is something to "explicit is better than implicit" mantra. 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.
- bluecalm 3y ago
  Man, this is completely unrelated problem. Implicit operator overload is just a bad design. 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.
  - masklinn 3y ago
    > Man, this is completely unrelated problem. 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.
    - bluecalm 3y ago
      You are not arguing in good faith but just in case I will point out what you are missing: 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.

hknapp 3y ago

https://stackoverflow.com/questions/13366083/why-does-the-arrow-operator-in-c-exist https://stackoverflow.com/questions/13366083/why-does-the-ar...

atilaneves 3y ago

Proof of the fact that this works is that D does exactly this.

masklinn 3y ago
AFAIK it works like that in most modern languages with pointers: Rust, Zig, even Go will implicitly deref pointers on attribute access.

Snarwin 3y ago

Interestingly, C already does this for function calls: "fptr()" is considered equivalent to "(*fptr)()".

kps 3y ago
A mistake, IMO; I want to be able to see right away whether a call target is static or dynamic.