Mirror of forum.nim-lang.org

91 :: Equality comparison for TTime

• gradha (orginal) [2012-10-18T22:31:41+02:00] view original

  I was writing a proc which accepts a default time as parameter. I decided to go with a default parameter of value TTime(0) and later branch if the parameter matches that value or not. My first try was:

  let final_date = if date < TTime(1): get_time() else: date
  Run

  Then I changed my mind and made it an equality like this:

  let final_date = if TTime(0) == date: get_time() else: date
  Run

  However this spits the following compiler message:

  seohyun.nim(35, 18) Error: type mismatch: got (TTime, TTime)
  but expected one of:
  system.==(x: T, y: T): bool
  system.==(x: ptr T, y: ptr T): bool
  system.==(x: set[T], y: set[T]): bool
  system.==(x: string, y: string): bool
  system.==(x: ref T, y: ref T): bool
  system.==(x: float, y: float): bool
  system.==(x: int64, y: int64): bool
  system.==(x: int, y: int): bool
  system.==(x: int32, y: int32): bool
  system.==(x: T, y: T): bool
  system.==(x: pointer, y: pointer): bool
  system.==(x: bool, y: bool): bool
  system.==(x: TEnum, y: TEnum): bool
  system.==(x: char, y: char): bool
  system.==(x: int8, y: int8): bool
  system.==(x: int16, y: int16): bool
  system.==(x: cstring, y: cstring): bool
  system.==(x: seq[T], y: seq[T]): bool
  Run

  I wonder if there's something missing in the times module for comparisons to work. I reckon the idea of using TTime as a distinct int type is nice on paper, but feels alien to not be able to use plain integers requiring type conversions everywhere.

---

• gradha (orginal) [2012-10-18T22:49:44+02:00] view original

  Ah, so the comparison was actually missing, pushing https://github.com/Araq/Nimrod/pull/231.

  BTW, didn't completely undestand the borrow pragma, maybe it could help somewhere defining the operations for comparisons for integers? Or would that only help if I created a distinct type of TTime?

---

• Araq (orginal) [2012-10-19T23:09:48+02:00] view original

  Borrow should help here, yeah.

  I'm still thinking about how abstract TTime is supposed to be; maybe we should embrace/document the fact that TTime is Posix's time_t and be done with it...

  (For the JS target that's not true but the JS target is a second class target anyway...)

---