reflection: add Base.infer_return_type utility
#52247
Conversation
aviatesk
force-pushed
the
avi/base-return_type
branch
from
c936a78 to
4c3a3bb
Compare
base/reflection.jl
Outdated
| world::UInt=get_world_counter(), | ||
| interp::Core.Compiler.AbstractInterpreter=Core.Compiler.NativeInterpreter(world)) -> rt::Type | ||
|
|
||
| Returns the return type of the function call specified by `f` and `types`. |
There was a problem hiding this comment.
Probably should say "a supertype of the return type"
And seems like Base.infer_return_type would be consistent with the names of other similar queries?
Also might want to add a See also ref to Base.promote_op & friends so that people get directed to ways to infer these for generated functions, rather than just being warned that using from a generated function is an error
There was a problem hiding this comment.
Probably should say "a supertype of the return type"
Maybe "an inferred return type" would be better? "supertype" sounds like returning something that is strictly wider in the type lattice. "inferred" might be a bit ambiguous, but it can still effectively communicate the idea.
There was a problem hiding this comment.
And seems like
Base.infer_return_typewould be consistent with the names of other similar queries?
Yeah. Base.infer_return_type isn't consistent with Base.return_types, but we might want to rename Base.return_types to Base.infer_return_types instead.
There was a problem hiding this comment.
Also might want to add a See also ref to
Base.promote_op& friends so that people get directed to ways to infer these for generated functions, rather than just being warned that using from a generated function is an error
Are you suggesting that when it's absolutely necessary to infer the return type from a generated context, we should lean towards using Core.Compiler.return_type? Or is the point more about using the docstring of promote_op as a means to highlight the nuances of using these reflection tools?
There was a problem hiding this comment.
It is never allowed directly, but you can pass it as an argument to the generated function
There was a problem hiding this comment.
Do you mean the implicit world::UInt argument that is passed to the generator function? I'm not sure how promote_op relates to generated functions.
aviatesk
changed the title
Base.return_type utilityBase.infer_return_type utility
This commit introduces `Base.infer_return_type`, a new reflection utility which shares a similar interface with `Base.return_types` but differs in its output; `Base.infer_return_type` provides a singular return type taking into account all potential outcomes specified with the given call signature. This function parallels `Base.infer_effects` and the newly added `Base.exception_type`, offering some utility, especially in testing scenarios.
aviatesk
force-pushed
the
avi/base-return_type
branch
from
4c3a3bb to
3b9eebb
Compare
This commit introduces `Base.infer_return_type`, a new reflection utility which shares a similar interface with `Base.return_types` but differs in its output; `Base.infer_return_type` provides a singular return type taking into account all potential outcomes specified with the given call signature. This function parallels `Base.infer_effects` and the newly added `Base.infer_exception_type`, offering some utility, especially in testing scenarios.
This commit introduces
Base.infer_return_type, a new reflectionutility which shares a similar interface with
Base.return_typesbutdiffers in its output;
Base.infer_return_typeprovides a singularreturn type taking into account all potential outcomes specified with
the given call signature. This function parallels
Base.infer_effectsand the newly added
Base.infer_exception_type, offering some utility,especially in testing scenarios.