Why isn't `size` always inferred to be an Integer?

julia> struct Bad <: AbstractVector{Int} end

julia> Base.size(::Bad, args...) = missing

Where is your god now?
Joking aside, the problem is that the compiler can’t prove that someone didn’t do the equivalent of what I just did above. That’s why it needs to return Any.


I wont go into discussing this as it quickly dives into territories where I cannot go, but it seems a week reason. If it can’t just error. The docs seem clear

size(A::AbstractArray, [dim])

  Return a tuple containing the dimensions of A.

Not necessarily. Even with only builtin types:

julia> R = big(1):big(2)^400

julia> length(R)

julia> typeof(ans)

julia> R isa AbstractArray

Fine. As long as it’s not a Any that keeps propagating. How can we be expected to prevent Any's propagation with all this?

And I think I meant an Integer

julia> BigInt <: Integer
1 Like

Converting it to an Int? I mean, if you know that is what it should be, let it be. :stuck_out_tongue:

Also, a function barrier may work? Don’t know the rest of the code so IDK.

1 Like

I don’t think the compiler reads the docs. If it can’t prove it, it has to be Any. I mean, how else could it work?

1 Like

Never fully Groked the concept but isn’t this type piracy? And if yes, why comply with it?

No, if Bad is your own type, you actually have to make your own size.


Knowing it’s gotta be an Integer is, really, not any better than Any for the purposes of the compiler and possible runtime speed. It still needs the costly indirection to figure out what instructions to use, and it can’t just shove it into a 64-bit register.


This is not type-piracy. The type Bad is defined inside the actual “module” and you define Base.size on it.

IIUC type piracy is that you define an external function to your module to a type external to it. Something like this

module A
function f() end

module B
struct MyType end

module C
import ..A: f
import ..B: MyType

function f(x::MyType) end # type piracy

Thanks, this I can understand.

And on the same spirit of this thread, how can a string return a Any

└────         goto #157
155 ─ %823  = GMT.string(val)::Any
│     %824  = (%823 != "indata")::Any

Same, even though we “know” the interfaces, the compiler cannot guaranteed always that they are respected.

I think you may be taking this output too seriously. Does it actually cause type instability to propagate in your package?

It’s not literally returning Any — the compiler just isn’t sure what it might return at runtime. And it’s because the compiler doesn’t know what type val will be, so it doesn’t know what method of string will be called.

Just as in the size example, the trouble isn’t so much string (or size), but upstream of that — sort out the stability of their arguments and they’ll then be stable.


Maybe not, but what I know is the module in question is precompiled and it still takes a further ~6 seconds to run on the first run. I try to reduce that and the only thing I can tie to the the potential instabilities … and ~zero success.

As @mbauman says it’s something else in the function thats unstable. You can fix that, or if thats not possible split the function into 2 functions to create a function barrier, so as much of it as possible is stable.

I know that, but in this case it’s an impossible task because those are derived from input arguments to the function and they can have different types. Nothing really important for run time … as long as per-compilation had worked well. But it didn’t and I’m just trying to find out why and the Any's are the beasts to chase, so we are told.

And to give it more context, this the function I’m referring to GMT.jl/psxy.jl at master · GenericMappingTools/GMT.jl · GitHub. The source of the Any's is the kwargs tht are converted into a Dict(:symbol, Any) and from there anything extracted from the Dict is a Any. Have no idea on how to work around this.
But again, this does not seem to hurt runtime … after compilation of first run, hence latency.

Type instabilities in end-packages tend to impact runtime speed, not the (pre-)compile time. In upstream libraries, yes, they can indeed become one of the magnets for invalidation, but I don’t think they’re typically troublesome at the point where I think you are.

This conversation is now circling back to the original thread from which it was split — we can go back to Taking TTFX seriously: Can we make common packages faster to load and use for concrete tips for reducing that compile time.

@mbauman dont type instabilities also account for a lot of (pre)compile time, because its more work for the compiler to resolve types?

In my experience fixing type stability absolutely reduces compile time.

1 Like