Avoid benevolent union behaviour for more type methods#1644
Conversation
5b44de1 to
d5366d8
Compare
|
the 8 failures so far seem to be unrelated. a couple of weird CI temp errors apparently as well, maybe this should be force-pushed / re-triggered later. I don't want to stress it even more now |
|
I'm sorry about the CI errors on 1.8.x. I'm working hard to remove these errors, they will get resolved before 1.8.3 is tagged. |
7e74981 to
eedd1f0
Compare
eedd1f0 to
a679877
Compare
|
I'd be happy to try this out (merge it) given some tests. Plain old unit tests in BenevolentUnionTypeTest (it might not exist yet) would be fine. |
a679877 to
0433e04
Compare
ondrejmirtes
left a comment
There was a problem hiding this comment.
I disagree with the can/has changes, only is* behaviour should be changed.
fair point, the idea was that e.g. calling methods on null would lead to a fatal error. but same thing for calling that on stdClass, so good with me. The only deviations (except isSuperTypeOf, isSubTypeOf and isAcceptedBy of course) are now only Another thought was that The tests added so far are really simple and stupid and mostly copy/paste as you can see, but maybe they help for future fixes or so. |
482ee85 to
b02fb50
Compare
|
Thank you! |
I mostly want to see what happens. Tbh this is more based on a gut feeling than any real data. E.g.
isIterableis still benevolent, otherwise trying to iterate over(array|null)is reported which results only in a warning and is most likely annoying. On the other hand trying to use(callable|null)as callable would be a fatal error in case it is null. Same forclone.This would also "fix"
isStringchecks IMO as mentioned in phpstan/phpstan#7833 (reply in thread) but it very much depends on the point of view I guess. I think e.g.(int|string)should not returnyesviaisString.