Nim: [regression?] correct comparisons for nil strings/seqs?

Created on 28 Jun 2018 · 9Comments · Source: nim-lang/Nim

given this test

proc test() =
  var a: string
  echo  a == nil
  a = ""
  echo a == nil
  var b: seq[int]
  echo b == nil
  b = @[]
  echo b == nil

test()

Nim 0.18.0 produces:

false
true
false

After commit correct comparisons for nil strings/seqs it produces:

true
true
true

Is this really what you mean by correct comparisons for nil strings/seqs?

(issue #8136 is related to this)

Source

skilchen

Most helpful comment

@dom96 I am sorry for you. But it will be for the greater good. And I think your example will still be understandable and valuable even if nil won't exist anymore in the language.

krux02 on 11 Jul 2018

❤1 👍1

All 9 comments

I think now nil seq/string is the same thing as empty seq/string and #8136 needs to be fixed accordingly with that change

hlaaftana on 28 Jun 2018

in the changelog we have this:

nil for strings/seqs is finally gone. Instead the default value for
these is "" / @[].

I don't understand how this could imply that both "" == nil and @[] == nil are now true, while isNil("") and isNil(@[]) remain false as before.

skilchen on 28 Jun 2018

👍2

I've said it before. New strings/seqs are coming and nil and isNil will fail to compile. No confusion will be possible.

Araq on 29 Jun 2018

🎉2

Excellent! Good luck with this abitious endeavor!

skilchen on 29 Jun 2018

can this be closed then?

krux02 on 9 Jul 2018

Not as long as isNil(str) compiles.

Araq on 9 Jul 2018

This will break my book :(

This example at least: https://github.com/nim-lang/Nim/blob/devel/tests/niminaction/Chapter2/resultaccept.nim

dom96 on 10 Jul 2018

@dom96 I am sorry for you. But it will be for the greater good. And I think your example will still be understandable and valuable even if nil won't exist anymore in the language.

krux02 on 11 Jul 2018

❤1 👍1