open up arg signature for Hash#slice #7822
Draft
Conversation
This file contains 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.
Hash#slicehas well-defined behavior for arguments that are not keys in the receiving hash: it leaves those keys out of the result object. The return type is still guarantee-able because arguments that don't match the key type will be absent in the result, but the argument type permits anything as input. Common use case for this is passing a nilable argument to a Hash that has typed non-nilable keys; the expected and actual result in the nil case is an empty hash.Motivation
https://github.com/sorbet/sorbet/pull/7789/files caused multiple lint failures in our codebase on valid Ruby
Addresses #7821
Test plan
Updated the test but leaving this in draft, still debating whether I need an additional assertion to test argument validity