-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[red-knot] Prefix Type::call
and dunder_call
with try
#16261
Conversation
Type::call
and dunder_call
with try
Type::call
and dunder_call
with try
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 renaming of the existing methods to Type::try_call()
, Type::try_call_bound
and Type::try_call_dunder
makes sense to me. I'm not sure I see the motivation for adding the unused Type::call()
, Type::call_dunder
and Type::call_bound
methods, though. They seem like they should be fairly easy to add if we ever need them?
@@ -2693,52 +2725,8 @@ pub enum KnownInstanceType<'db> { | |||
} | |||
|
|||
impl<'db> KnownInstanceType<'db> { | |||
pub const fn as_str(self) -> &'static str { |
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.
Nice catch!
I think it helps establish the pattern and it more clearly communicates the idea. It also provides a place to document where they should be used. My last argument is that I'm often too lazy to add methods like this if I have to use them the first time and I only add them if I rewrote the same code like 10 times. Maybe that's a good thing but I want to take that burden from future me. But I don't feel strongly. Removing them just means that we'll have some |
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 lean towards leaving out the unused methods until we need them, since we should usually encourage people to use the methods that return Result
s in most contexts anyway. But I also don't feel too strongly :-)
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 like the pattern, but I also think that we should omit methods that we don't currently need (and IMO it is not clear if we will ever need them.) I think the existence of try_call
already strongly implies the pattern even if call
doesn't exist (yet).
This will cause more rebase pain for @sharkdp on the descriptors PR :)
|
Summary
This PR prefixes the
Type::call
anddunder_call
methods withtry
to make it more explicit that they return aResult
and add
call
anddunder_call
methods that return the return-type without aResult
. These new methods are intendedto be used outside of type checking.
This follows an existing pattern:
The main motivation for this change is #16238 because it is somewhat common to call
bool
outsideof type checking -- Making it desirable to have to dedicated methods for it. Splitting the methods also helps improving performance
because we can skip some analysis when we don't care about errors.
Test Plan
cargo test