isEmpty for Deque type

[disruptek]

We talked about implementing this for collection types; here's one.

[disruptek]

Who thinks we should just have a template that tries to len() on the target?

[metagn]

That, or

template isEmpty(x): bool =
  var result = true
  for _ in x:
    result = false
    break
  result

Works for iterators and efficient for cstring/lists.

[alehander92]

the iterator thing should be only a overload for the other cases imo

[metagn]

If you use len then you're going to have to overload it for every type that has a non-constant len. Everything has an iterator. We should start overloading when we get container concepts like nim-lang/RFCs#50.

[alehander92]

you're right. however an iterator can take a lot of time to produce its first element : in this case you also need to overload isEmpty as it would be probably faster.
overally, one should apply common sense and overload isEmpty if it is really required for his data structure

[alehander92]

I wouldn't want nim to produce C code for a 1 or 2 assignments + a loop just for an access to a len/count field in some cases. hm I don't think it would be optimized well enough but i might be wrong?

[Araq]

This is how it should be done

template isEmpty*(x: typed): bool = x.len == 0
# added to system.nim

proc isEmpty*(x: cstring): bool {.inline.} = x == nil or x[0] == '\0' # specialization

Yes, it's a system.nim extension but a good one.

[alehander92]

well, an overload for cases where there is no len but there is items might be still cool, but the len, but slower case still would need a manual overload then..

[metagn]

Maybe len should be renamed to getLen for those (which means len would be deprecated for cstring, but only in C/C++/objc, which is inconvenient). Or some no-op symbol like template lenIsSlow(x: cstring): bool = discard, then you check when compiles(lenIsSlow(x)), which means you can also put it in a concept.

Edit: The types in the lists module don't even have a len overload, you don't need special treatment for them, just compiles(x.len). len for cstring should be deprecated and there should a generic getLen that uses items. Also that cstring overload is bound to be faster than any generic one so it doesn't matter.

[alehander92]

getLen seems confusing , because it's not obvious what the difference is: maybe slowLen or nonConstLen (yeah i know) is still better, but overally encoding complexity in this is hard

[metagn]

I have a new name, count. Wrote another RFC nim-lang/RFCs#217

PR can do Araq's suggestion for now but maybe with when not declared(x.len) support with my snippet.

[disruptek]

Closing for nim-lang/RFCs#217 -- thanks for moving the ball forward!