Equality and truthiness of string#elems

[fmeum]

The spec isn't clear on how equality and truthiness should behave for the value returned by string#elems (and similar Sequences).

The available implementations differ:

• Java

>> bool("".elems())
False
>> "foo".elems() == "foo".elems()
True

• Go

>>> bool("".elems())
True
>>> "foo".elems() == "foo".elems()
True

• Rust

$> bool("".elems())
True
$> "foo".elems() == "foo".elems()
False

In Python, custom iterables (such as generator expressions) are often truthy regardless of whether they are non-empty and non-identical generator objects are distinct even if they yield the same elements (ignoring e.g. range, which is specced to determine equality as sequences), which matches the behavior of the Rust implementation.

@adonovan @stepancheg @brandjon What are your thoughts on this?

Edit: Noticed that Python generator expressions are always truthy, not just when non-empty.

[adonovan]

The spec should probably take a position one way or another. I think making iterators non-equal even if their sequences are equal is probably the prudent course; even if in the string case it's easy either way, for other iterators, determining that they generate equal elements may not be a cheap computation.

[brandjon]

See also #292. We could define equality/truthiness of sequences to always be based on their content, and say for non-sequence iterables this may or may not hold.

You'd think an iterable should be reflexively equal to itself, but that doesn't mean that calling .elems() always gives you the same iterable.