...instead of Union{Container{A}, Container{B}}
. Or in other words, getting discount parametric sum types without specifying the type parameters :stuck_out_tongue_wink:
To avoid the X-Y problem, here are the precise lines of code I'm thinking about with this question: https://github.com/FluxML/Flux.jl/pull/2005/files#diff-344cb9517a6c67cbcc6d110732e3f12cc908b8f4b5eeee46571218f5175d7e32R48-R66. After poking around I have not found a way to avoid return_type
, so my hope is to nerd-snipe someone here into helping.
I wonder if you could get away with a return type assertion here?
have you tried that?
You mean in lieu of the return_type
call? Unfortunately I don't have a type to assert with if I drop that.
not sure that transform is legal
the outer Union may have a different memory layout than the inner union
e.g. think of the layout of Union{Container{Int}, Container{Float64}}
vs. Container{Union{Int, Float64}}
those are two (three) totally different objects
Yes, I'm aware of that. My point is that I can't even ask for the different Union coalescing behavior if I wanted to
Not being able to reify unions generated by diverging -> converging control flow like this means that a lot of otherwise type stable functions are doomed to be type unstable once they're run through AD.
Yeah, this is an interesting case. Looking with fresh eyes I see the problem. I think this is a case where I’d feel pretty shameless about using return_type
I think this is a legitimate use case because so far as I can tell, you’re not modifying the behaviour based on the inference result, you’re just providing a more efficient smart container. If inference changes to give Any
or any other wider type, this would still be correct, just slower
Last updated: Nov 06 2024 at 04:40 UTC