Repository navigation
Prepare 0.1 code for the 0.2 upgrade - #55
Merged
Merged
Conversation
0.2 makes forEach(), forEachKey() and forEachValue() return void and moves chaining to onEach(), onEachKey() and onEachValue(). Ship the onEach*() methods here already, so code chaining off forEach*() can switch while still on 0.1 and then upgrade without further changes. The methods live in CollectionLogic and MapLogic, delegating to forEach*(). The interfaces declare them through @method tags rather than natively: adding a method to an interface would break classes implementing it without the logic traits, which 0.2 is allowed to do but a 0.1 patch is not. Each interface narrows the return type the same way its forEach*() declaration does, so PHPStan and IDEs keep the precise type along a chain. forEach*() itself is left untouched and not deprecated: it stays in 0.2, only its return type changes, and PHP cannot tell whether a caller uses the result. The API reference and cheatsheet point to onEach*() instead.
0.2 removes the default value of mapOfPairs()'s $data parameter, matching mutableMapOfPairs(). Trigger E_USER_DEPRECATED when it is called without arguments, pointing to mapOf() for an empty map. An explicit empty iterable stays silent.
List the breaking changes between 0.1 and 0.2 with the replacement for each: forEach*() returning void, mapOfPairs() requiring its argument, the map logic traits declaring $store once, and the methods new interface implementers must add. Note the zip() behaviour change and the new NoctudCollectionException marker, and point to 0.1.8 for migrating ahead of the upgrade.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
delacry
added a commit
that referenced
this pull request
Oct 10, 2026
List the breaking changes between 0.1 and 0.2 with the replacement for each: forEach*() returning void, mapOfPairs() requiring its argument, the map logic traits declaring $store once, and the methods new interface implementers must add. Note the zip() behaviour change and the new NoctudCollectionException marker, and point to 0.1.8 for migrating ahead of the upgrade. (cherry picked from 53e6249, #55 on 0.1.x)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bridge release for 0.1.8: everything a 0.1 user needs to make their code work on both 0.1 and 0.2 before bumping the constraint.
onEach(),onEachKey(),onEachValue(). 0.2 makesforEach(),forEachKey()andforEachValue()returnvoidand moves chaining toonEach*(). TheonEach*()methods ship here already, so chained calls can switch now:They are real methods in
CollectionLogicandMapLogic, but the interfaces declare them through@methodtags rather than natively. Adding a method to an interface would break classes implementing it without the logic traits, which 0.2 may do but a 0.1 patch should not. Each interface narrows the return type the same way itsforEach*()does, so PHPStan and IDEs keep the precise type along a chain (ImmutableList::onEach(): ImmutableList<E>,MutableTrackedMap::onEach(): MutableTrackedMap<K,V>&TrackedResult, ...).forEach*()itself is unchanged and not deprecated: it stays in 0.2, only the return type changes, and PHP cannot tell whether a caller uses the result. After upgrading, PHPStan reports every affected call asResult of method ...::forEach() (void) is used.mapOfPairs()without arguments. 0.2 makes$datarequired, matchingmutableMapOfPairs(). Calling it with no arguments now triggersE_USER_DEPRECATEDpointing tomapOf(); an explicit empty iterable stays silent.UPGRADE-0.2.md. Lists every break with its replacement:forEach*()returningvoid,mapOfPairs()requiring its argument,MapLogicdeclaring$store(with exactly which$storedeclarations now fail and which do not), and the methods direct interface implementers must add. Also notes thezip()behaviour change and the newNoctudCollectionExceptionmarker. It should be cherry-picked onto 0.2.x as well.The API reference and cheatsheet mention
onEach*()and the upcomingforEach*()change.Tests:
onEach*()runtime tests ported from 0.2.x;tests/Type/OnEachTypeTest.phppins the narrowed return type on all 24 interfaces;mapOfPairs()with and without arguments.