Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Throw an exception when attempting to count a generator #1672

Closed
wants to merge 2 commits into from

Conversation

duncan3dc
Copy link
Member

Generators are often looped around, and where you have code that accepts a traversable, it's logical to try and count it. At the moment counting a generator returns int(1), so the unsupported behaviour can easily go unnoticed.

This pr proposes to change that by throwing an exception whenever code attempts to count a generator

@jpauli
Copy link
Member

jpauli commented Dec 24, 2015

This can't target PHP 7.0 as it breaks API.
It can target PHP 7.1 though.
ping @nikic ?

@nikic
Copy link
Member

nikic commented Dec 24, 2015

@jpauli I think this is a good change.

However I wonder whether we shouldn't make this an error for all counts on non-Countable objects. The current behavior is very useless and probably easy to make a mistake if you're working with iterators.

@duncan3dc
Copy link
Member Author

duncan3dc commented Dec 24, 2015 via email

@jpauli
Copy link
Member

jpauli commented Jan 4, 2016

@nikic I'm also +1 to throw an Exception on any count operation involving non-countable object , but that should target 8.0

@duncan3dc I think having a patch just for the Generator case makes little sense if we choose to apply it to every object. I guess it is time to propose such a change into an RFC

@nikic
Copy link
Member

nikic commented Jan 4, 2016

An RFC should be able to target this at 7.1. Whether it will pass likely depends on whether someone finds a legit BC concern with the change.

@jpauli
Copy link
Member

jpauli commented Jan 4, 2016

I think the BC is too big for a minor and should target a major

@jerrygrey
Copy link

Throw an Exception for all non-countable objects is a good idea, I'm surprised it doesn't do it already.

@morrisonlevi
Copy link
Contributor

Something that is related: foreach on objects that do not implement Iterator will iterate over the visible properties. It is my opinion that these should be tackled in connection with each other.

@nikic
Copy link
Member

nikic commented Jan 29, 2016

@jpauli How about a warning? Exceptions in standard library are a tricky issue, but I don't think anybody would have a problem with a warning.

@morrisonlevi That seems unrelated, and the current behavior is an explicitly supported feature. I'd appreciate the introduction of a proper property iterator type, which would allow us to phase out this behavior in the future, however I don't see the relation to count().

@jpauli
Copy link
Member

jpauli commented Jan 29, 2016

@nikic Why not, but this would BC as well :-p

@duncan3dc
Copy link
Member Author

@jpauli What about E_DEPRECATED for 7.*?

@nikic
Copy link
Member

nikic commented Jan 29, 2016

@jpauli I don't think we consider throwing additional non-fatal diagnostics to be a BC break. We really should specify this kind of stuff.

@jpauli
Copy link
Member

jpauli commented Jan 29, 2016

To be asked to the RM :-)

@morrisonlevi
Copy link
Contributor

In any case throwing an exception or raising an error should not be specific to Generators in my opinion. It's the same exact logic issue with all other non-Countable objects. I think we should not special case the Generator.

Said otherwise we should raise an error/warning/notice for all non-Countable objects (not just Generators)

@jpauli
Copy link
Member

jpauli commented Jan 29, 2016

@morrisonlevi I tend to agree here, though I'm still not sure it should be done in a minor

@duncan3dc
Copy link
Member Author

Thanks for the input everyone, the RFC is up for discussion now

@duncan3dc duncan3dc closed this Oct 4, 2016
@duncan3dc duncan3dc deleted the prevent-generator-count branch October 4, 2016 20:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants