-
Notifications
You must be signed in to change notification settings - Fork 565
Implement Array#dig
and Hash#dig
intrinsic
#6491
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
Conversation
We have a policy of testing changes to Sorbet against Stripe's codebase before Stripe employees can see the build results here: → https://go/builds/bui_Me1jkvpSlKWnlg |
We have a policy of testing changes to Sorbet against Stripe's codebase before Stripe employees can see the build results here: → https://go/builds/bui_Me2VK5QEWfwzBc |
args.locs.file, // file | ||
args.locs.call.copyWithZeroLength(), // call | ||
args.locs.args[0].copyWithZeroLength(), // receiver | ||
args.locs.args[0].copyWithZeroLength(), // fun |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this just args.locs.fun
? I don't know if it makes a difference whether you copyWithZeroLength()
, but I think it would make things slightly more consistent to use args.locs.fun
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so?
opts.dig("first", "second")
^^^ fun
^^^^^^^ args[0]
Having it be zero length makes it basically ignore it for most things, and use the callLoc
instead, except that it's very hard to get a case where it would need to use these errors, because we know that the Array#at
/ Hash#[]
methods always exist, so we're unlikely to need the fun
locs. The most important location in practice is the basecaseArgLocs in case you try to pass 0
to a T::Hash[String, ...]
or something.
args.locs.file, // file | ||
args.locs.args[1], // call | ||
args.locs.receiver, // receiver | ||
args.locs.args[1].copyWithZeroLength(), // fun |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also args.locs.funLoc
. I guess we can use it as-is here, because the loc ought to be for dig
, and that's what we're re-dispatching to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, I think this is not funLoc, due to above.
# Shapes are bad--ideally lot of these would be errors | ||
sig {params(opts: AShapeType).void} | ||
def example4(opts) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The TODO
in the corresponding exp file says we should have some tuple tests too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
example7
Co-authored-by: Nathan Froyd <froydnj@gmail.com>
Co-authored-by: Nathan Froyd <froydnj@gmail.com>
Motivation
#6468
Test plan
See included automated tests.