Mirror of forum.nim-lang.org

5185 :: Confusion on implicit integer conversion.

• mp035 (orginal) [2019-09-10T12:18:01+02:00] view original

  Couldn't render post #32509.

---

• mratsim (orginal) [2019-09-10T17:35:42+02:00] view original

  The signature of the proc is

  proc `+`[T: SomeInteger](x, y: T): T
  Run

  T is bound to uint32 in the first case, and we can convert uint16 to uint32 losslessly. In the second case, T is bound to uint16 and we can't convert uint32 to uint16 losslessly.

---

• cdome (orginal) [2019-09-10T18:03:37+02:00] view original

  there is module in standard library: lenientops.

  it should help

---

• mp035 (orginal) [2019-09-11T00:47:33+02:00] view original

  @cdome, thanks for the suggestion, but I am working with serial protocols involving integers of different lengths, so lenientops is not much help. It works by converting between int and float. @mratsim, thank you for the explanation. As an experienced user (I've seen your sig many times) can you shed some light on why the language imposes this restriction? Nim is an extremely complicated language making it quite difficult to learn. It seems to be a very poor design choice to overly complicate even this most basic of operations by imposing operand order. Is there an underlying advantage somewhere that I am missing? What is wrong with promoting either operand (the way every other language ever invented does)? This is not intended to be a rant, I'm just trying to understand the motivation. Thanks again for your advice.

---

• mashingan (orginal) [2019-09-11T05:35:21+02:00] view original

  tldr; if the size of integer is important, always opt to explicit conversion

  ---

  you can define your own + operator for your case

  proc `+`(x: uint16, y: uint32): uint32 = x.uint32 + y
  Run

  But then the definition then become tedious if you have to define another with

  proc `+`(x: uint32, y: uint64): uint64 = x.uint64 + y
  Run

  again and again. So the + is defined as generic. Since generic doesn't know which type should it bind to, so it's logical choice to bind to first argument.

---

• mratsim (orginal) [2019-09-11T05:41:57+02:00] view original

  I'd also add to @mashingan answer than Nim is a strongly typed language. Lossless conversion are made explicit for safety reason, we don't want you to lose information or data by something done under-the-hood and very time-consuming to debug.

  Other strongly typed languages might just plain prevent you from promoting uint16 to uint32 implicitly.

---

• mp035 (orginal) [2019-09-11T07:02:14+02:00] view original

  @mashingan >tldr; if the size of integer is important, always opt to explicit conversion That seems to be very good advice. I was considering defining my own operators, but it seems like the first option is the most sensible.

  @mratsim I had never actually considered C to be a 'weakly typed' language. There seem to be various opinions on that particular subject both for and against. I can see what you are saying though, C is definitely more weakly typed than Nim, and I had not considered the differences in philosophy.

  Thanks again everyone for your advice.

---

• Araq (orginal) [2019-09-11T08:29:02+02:00] view original

  IMO it's just a system.nim bug caused by misunderstandings about how generic parameters work.

---

• mp035 (orginal) [2019-09-11T14:07:45+02:00] view original

  @Araq Should I raise an issue? Also would you be able to elaborate on 'how generic parameters work'?

---

• Araq (orginal) [2019-09-11T14:26:03+02:00] view original

  Couldn't render post #32528.

---

• jibal (orginal) [2019-09-13T06:09:44+02:00] view original

  I had never actually considered C to be a 'weakly typed' language. There seem to be various opinions on that particular subject both for and against.

  There is far less debate about whether C is weakly typed than there is about what the term means. I used the language for 40 years and served on the C language standards committee and I've never seen any sign of a debate on this issue -- no one has ever called C strongly typed. I could point to printf and casting of pointers to other pointer types (or to and from void* without even needing a cast) or even to integers (when I started using C you didn't even need a cast) as glaring examples.

---