3 ms·

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

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.
      - masklinn 3y ago
        > You are not arguing in good faith 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.
- sigsev_251 3y ago
  Integer promotion will probably never be removed from the fundamental types (char, signed char, short, etc.). You can use `_BitInt`(N) types in the future which don't follow the implicit integer promotion rule. There are at least two compilers today that implement it (clang and SDCC).
  - masklinn 3y ago
    > Integer promotion will probably never be removed from the fundamental types 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.

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.
    - masklinn 3y ago
      > You are not arguing in good faith 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.
sigsev_251 3y ago
Integer promotion will probably never be removed from the fundamental types (char, signed char, short, etc.). You can use `_BitInt`(N) types in the future which don't follow the implicit integer promotion rule. There are at least two compilers today that implement it (clang and SDCC).
- masklinn 3y ago
  > Integer promotion will probably never be removed from the fundamental types 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.