Inference failure for Ref{Int}?

[kcajf]

julia> struct Foo
           i::Ref{Int}
       end

julia> f = Foo(Ref(0))
Foo(Base.RefValue{Int64}(0))

julia> g(x) = x.i[]
g (generic function with 1 method)

julia> @code_warntype g(f)
Variables
  #self#::Core.Const(g)
  x::Foo

Body::Any
1 ─ %1 = Base.getproperty(x, :i)::Ref{Int64}
│   %2 = Base.getindex(%1)::Any
└──      return %2

julia> versioninfo()
Julia Version 1.6.0-DEV.1227
Commit 86bbe0941c (2020-10-15 00:29 UTC)

I thought this would infer the return type as Int, but it only manages Any. Am I doing something wrong, or is this expected? Is there a situation where the dereference can return something other than Int?

[vchuravy]

The issue is that Ref is an abstract type. The concrete type is RefValue.

julia> struct Foo{R<:Ref}
           i::R
       end

julia> g(x) = x.i[]
g (generic function with 1 method)

julia> f = Foo(Ref(0))
Foo{Base.RefValue{Int64}}(Base.RefValue{Int64}(0))

julia> @code_warntype g(f)
Variables
  #self#::Core.Compiler.Const(g, false)
  x::Foo{Base.RefValue{Int64}}

Body::Int64
1 ─ %1 = Base.getproperty(x, :i)::Base.RefValue{Int64}
│   %2 = Base.getindex(%1)::Int64
└──      return %2

So certainly a gotcha, I wouldn't classify it as an inference failure.

[kcajf]

Thanks @vchuravy , good to know! I'll use RefValue.

[martinholters]

Yes, generally better to use Base.RefValue here, but his particular case would also be helped by the following change:

--- a/base/refpointer.jl
+++ b/base/refpointer.jl
@@ -178,7 +178,7 @@ unsafe_convert(::Type{Ptr{T}}, r::Ptr{NTuple{N,T}}) where {N,T} =
 
 ###
 
-getindex(b::RefArray) = b.x[b.i]
+getindex(b::RefArray{T}) where {T} = b.x[b.i]::T
 setindex!(b::RefArray, x) = (b.x[b.i] = x; b)
 
 ###

Note that eltype(Ref{Int}) also promises an Int, so might be worth type-asserting this here anyway. (Or else provide an eltype(Type{<:RefArray}) that delegates to the eltype of the backing array.)

[mchitre]

RefValue isn't exported. Better to use it or better to parametrize the struct?

Parametrization feels like an awkward hack as I don't need the struct with any other type than the one declared, and with multiple Ref fields can get messy.

[KristofferC]

Maybe make the struct mutable and const annotate the rest of the fields?

[mchitre]

Any cost to a mutable struct with all constant fields as compared to an immutable struct?

[StefanKarpinski]

They have somewhat different semantics: the identity of two identical mutable structs must remain separate (and more importantly coherent), so it's harder for the compiler to completely eliminate allocations. The most straightforward and default way to ensure that is to actually allocate objects with location-based identity.

mutable struct M
    const f::Int
end

struct I
    f::Int
end

# basic identity
julia> I(1) === I(1)
true

julia> M(1) === M(1)
false

# more complex example for I
julia> a = I(1)
I(1)

julia> b = I(1)
I(1)

julia> c = a
I(1)

julia> a === b
true

julia> a === c
true

julia> b === c
true

# more complex example for M
julia> a = M(1)
M(1)

julia> b = M(1)
M(1)

julia> c = a
M(1)

julia> a === b
false

julia> a === c
true

julia> b === c
false

The language needs to ensure that for type M the values a and b are not the same object, whereas a and c are the same object. For the type I there's no such consideration since any instance of I with the same value is the same object, so we don't need to keep track of different ones.