Consider deprecating iter

I think iter should probably not be part of the library’s public API surface.

Strings and arrays are already iterables. A deprecation notice could warn users when an object is passed to iter, informing them that they should use entries instead.

Internally a function called iter could continue to be used with the same basic responsibility of making an iterator out of an iterable.

[sithmel]

I was already happy removing “entries” from iter. That was super confusing: “What if I want the entries of an object but this is already iterable ?”

About the other changes, I had to review carefully the specs (and your comments @conartist6) to form myself an opinion. What is important IMO was to be able to work with any object you could pass to “for … of” and to return an object you can pass to the “for…of”. In the specs it states that “for …of” works with object implementing the iterable protocol.

This is implemented by generator objects built-in objects like arrays, strings, etc. , and custom object with @@iterator. So what is left out?

• random objects implementing “next”, but they don’t work with the for … of loop already

So I am positive with these changes and the PR.

[sithmel]

Previous implementation was based on a few misconceptions of its author: myself 🤣