-
Notifications
You must be signed in to change notification settings - Fork 512
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
Better return type inference for proc and lambda values #4149
Labels
enhancement
New feature or surprising current feature
hard
Daunting task, even for Sorbet team members
Milestone
Comments
jez
added a commit
that referenced
this issue
Apr 25, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
jez
added a commit
that referenced
this issue
Jun 28, 2024
Sometimes it's useful to be able to use the arity of the block to guess an overload. This isn't perfect for all the reasons that overload checking isn't perfect, but there are some places where this is useful, especially in abstractions that check the proc's arity when deciding how to call the block. This is also a pre-requisite for doing something like #7741, which is a partial fix for #3914 / #4149, where we infer the types of `Kernel#lambda` blocks by codegenerating overloaded signatures.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
enhancement
New feature or surprising current feature
hard
Daunting task, even for Sorbet team members
Input
→ View on sorbet.run
Observed output
Expected behavior
It's very unexpected that
Proc.new
returnsT.untyped
It's somewhat unexpected that the inferred return types are
T.untyped
It's actually expected that the arguments don't have an inferred type. Sorbet makes no effort to infer arguments (this is true for methods too). We might want to expose a way to annotate argument types for proc/lambda values, but that is out of scope for this issue.
The text was updated successfully, but these errors were encountered: