Good price.

  • Victor@lemmy.world
    cake
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    6 months ago

    What I mean is that in JS you can’t do NaN != NaN, not even variable != NaN. So you’re not saying it’s the same in Go, since you can do a != nil?

    • nickwitha_k (he/him)@lemmy.sdf.org
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      6 months ago

      Kinda. nil is a weird value in Go, not quite the same as null or None in JS and Python, respectively. A nil value may or may not be typed and it may or may not be comparable to similar or different types. There is logical consistency to where these scenarios can be hit but it is pretty convoluted and much safer, with fewer footguns to check for nil values before comparison.

      I’m other words, in Go (nil == nil) || (nil != nil), depending on the underlaying types. One can always check if a variable has a nil value but may not be able to compare variables if one or more have a nil value. Therefore, it is best to first check for nil values to protect against errors that failure to execute comparisons might cause (anything from incorrect outcome to panic).

      ETA: Here’s some examples

      // this is always possible for a variable that may have a nil value. 
      a != nil || a == nil
      
      a = nil
      b = nil
      // This may or may not be valid, depending on the underlying types.
      a != b || a == b
      
      // Better practice for safety is to check for nil first
      if a != nil && b != nil {
          if a == b {
              fmt.Println("equal")
          } else {
              fmt.Println("not equal")
          }
      } else {
          fmt.Println("a and/or b is nil and may not be comparable")
      }
      
      • Victor@lemmy.world
        cake
        link
        fedilink
        arrow-up
        2
        ·
        6 months ago

        Thoroughly confusing lol. I think I need to check the spec in order to grasp this. I feel like this has more to do with the typing system rather than nil itself, maybe. I’ll see.

        But yeah, this is nothing like null or undefined in JS, but more similar to NaN.

        Thank you for trying to explain!

        • nickwitha_k (he/him)@lemmy.sdf.org
          link
          fedilink
          arrow-up
          2
          ·
          6 months ago

          Yeah… It’s weird but I find it useful that it is, in a weird way. Treating it as an uncertainty means that one MUST explicitly check all pointers for nil as part of normal practice. This avoids NPEs.