Mirror of forum.nim-lang.org

48 :: Integer promotion rules

• Araq (orginal) [2012-06-28T23:33:47+02:00] view original

  I did some experiments with the idea of making integer literals their own type to make code like myInt16 += 1 compile but decided that it's too complex as -1 or 5+6 should be of the integer literal type too then and thus the type would somewhat depend on the compiler's constant folding capabilities.

  Instead I plan to have these integer promotion rules:

  1. Widening conversions are implicitely done (int16 -> int32 is fine). Except int64 every integer type is implicitely convertible to int.
  2. Conversions from int are preferred over other conversions and narrowing is fine for int.

  This has the effect that the language does not promote i16 + 23 to int anymore; which is convenient for some embedded systems. Of course the same applies to int32, so the pain to work with int32 throughout for cache efficiency should be significantly lessened.

  The compiler rejects constant literals that are not in the range of the target type, so 34'i16 + 200_000 will produce a compile-time error ("cannot convert 200_000 to int16"). There will also be warning message emitted for implicit narrowing conversions like myIntVar + i16.

  Oh, and I've already implemented these new rules and afaict they don't break any code.

  Opinions?

---

• exhu (orginal) [2012-06-29T10:58:13+02:00] view original

  Tried and happy.

---

• Araq (orginal) [2012-06-29T11:08:36+02:00] view original

  Ha, I haven't pushed them yet, so I don't think you tried them. They are however similar to the previous rules. ;-)

---

• adrianv (orginal) [2012-06-29T15:28:08+02:00] view original

  sounds good. I am eager to test it.

---

• ventor3000 (orginal) [2012-07-03T08:28:30+02:00] view original

  Not exactly in topic, but it would be nice if integers were implictly castable to floats, since an integer always fits in a float. For example:

  proc test(a,b:float):

  return a*b

  test(4,5) #error, cannot cast int to float automatically

  /Robert

---

• Araq (orginal) [2012-07-03T10:01:09+02:00] view original

  But a 64 bit integer does not always fit in a 64 bit float. ;-) However since this rule is now relaxed for the other integer types, it's consequent to do the same for floats. I will add this feature and see what it does to the code base. :D

---

• adrianv (orginal) [2012-07-05T09:53:27+02:00] view original

  found some errors, which seem to come from the new rules. reported them on github

---

• Araq (orginal) [2012-07-08T22:36:02+02:00] view original

  I changed the integer promotion rules again as it's just too crazy to narrow an int to an int16 (it caused bugs in the compiler itself too). The new rules are quite complex, but lead to intuitive behaviour. The compiler is also now smarter so myByte = myInt and 0xff is valid. :D

  The details are here: http://build.nimrod-code.org/docs/manual.html#pre-defined-integer-types
  and here: http://build.nimrod-code.org/docs/manual.html#subrange-types
  

  The change that breaks most code is that int is not converted implicitely to int32 anymore as this can lose information on 64bit systems. Please complain if it breaks too much code; I may add this conversion back then...

---

• renoX (orginal) [2012-07-09T10:57:21+02:00] view original

  Hello,

  Is-it possible to define TSubrange = range[0..UINT_MAX]? And what happens when an operation overflow the range?

  Thanks.

---

• adrianv (orginal) [2012-07-09T12:13:04+02:00] view original

  There seems still some work to do - this does not compile anymore:

  
  var x = 1
  
  x += x and 1
  Run

  but this does :

  
  
  inc(x, x and 1)
  
  Run

---

• Araq (orginal) [2012-07-09T14:08:31+02:00] view original

  Is-it possible to define TSubrange = range[0..UINT_MAX]? And what happens when an operation overflow the range?

  No, uint and uint64 are no ordinal types for implementation simplicity. The compiler would need to use bignums internally everywhere then and that's too much work for now. However range[0u16 .. high(uint16)] is merely an alias for uint16; you can't get overflow checking for unsigned this way. If you want sane semantics, screw unsigned numbers: http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/

  There seems still some work to do ...

  Your help is really appreciated. And yeah I noticed many bugs too. I'm working on it. ;-)

---

• Araq (orginal) [2012-07-10T21:00:11+02:00] view original

  Update: I now consider the implementation of the new integer promotion rules stable, so please test and give feedback. (And no, don't bother me with unsigned integer bugs; support for unsigned numbers is still work in progress...)

---