It's becausematchingvalue gets called on all the model function's arguments, and types can be arguments to the model as well, e.g.

@modelfunctionf(x, T)...endmodel=f(1.0, Float64)

This change was made here:

#191

The motivation is here:

TuringLang/Turing.jl#1464 (comment)

This has to do with some subtle mutation behaviour. For example

@modelfunctionf(x)    x[1]~Normal()end

Ifmodel = f([1.0]), the tilde statement is an observe, and thus even if you reassign tox[1] it doesn't change the value ofx. This is the!hasmissing branch, and since overwriting is a no-op, we don't need to deepcopy it.

Ifmodel = f([missing]) - the tilde statement is now an assume, and when you run the model it will sample a new value forx[1] and set that value inx. Then if you rerun the modelx[1] is no longer missing. This is the case where deepcopy is triggered.

So apart from the deepcopy to avoid aliasing, the other place wherematchingvalue does something meaningful is

@modelfunctionf(y,::Type{T}=Float64)where {T}    x=Vector{T}(undef,length(y))for iineachindex(y)        x[i]~Normal()        y[i]~Normal(x[i])endendmodel=f([1.0])

If you just evaluate this normally with floats, it's all good. Nothing special needs to happen.

If you evaluate this with ReverseDiff, then things need to change. Specifically:

1. x needs to become a vector ofTrackedReals rather than a vector of Floats.
2. In order to accomplish this, the ARGUMENT to the model needs to change: even thoughT SEEMS to be specified as Float64, in fact,matchingvalue hijacks it to turn it intoTrackedReal when callingmodel().
3. How doesmatchingvalue know that it needs to become a TrackedReal? Simple - when you calllogdensity_and_gradient it callsunflatten to set the parameters (which will be TrackedReals) in the varinfo.matchingvalue then looks inside the varinfo to see if the varinfo containsTrackedReals! Henceeltype(vi) 🙃

It actually gets a bit more complicated. When you define the model, the@model macro already hijacks it to turnT intoTypeWrap{Float64}(), and then when you actually evaluate the modelmatchingvalue hijacks it even further to turn it intoTypeWrap{TrackedReal}(). Not sure why TypeWrap is needed but apparently it's something to do with avoiding DataType.

ForwardDiff actually works just fine on this PR. I don't know why, but I also remember there was a talk I gave where we were surprised that actually ForwardDiff NUTS worked fine without special::Type{T}=Float64 stuff, so that is consistent with this observation.

So this whole thing pretty much only exists to make ReverseDiff happy.

^{To get around this, I propose that we drop compatibility with ReverseDiff}

Actually, for most models, ForwardDiff and ReverseDiff still work because of this special nice behaviour:

julia> x= Float64[1.0,2.0]2-element Vector{Float64}:1.02.0julia> x[1]= ForwardDiff.Dual(3.0)# x[1] ~ dist doesn't do thisERROR: MethodError: no method matchingFloat64(::ForwardDiff.Dual{Nothing, Float64, 0})The type`Float64` exists, but no method is definedfor this combination of argument types when trying to construct it.julia> x= Accessors.set(x, (@optic _[1]), ForwardDiff.Dual(3.0))# x[1] ~ dist actually does this!2-element Vector{ForwardDiff.Dual{Nothing, Float64,0}}:Dual{Nothing}(3.0)Dual{Nothing}(2.0)

There is only oneerroring test in CI, which happens because the model explicitly includes the assignmentx[i] = ... rather than a tilde-statementx[i] ~ .... Changing the assignment to useAccessors.set makes it work just fine.

BUT there arecorrectness issues with ReverseDiff (not errors), and I have no clue where those stem from. Andreally interestingly, it's only a problem for one of the demo models, not any of the others, even though many of them use theType{T} syntax.

Somatchingvalue used to deepcopy things sometimes. Right now I work around this by indiscriminatelydeepcopying. This is a Bad Thing and we should definitely have more careful rules about when something needs to be deepcopied. However, I don't believe that such rules need to use the wholematching_type machinery.

Indiscriminately deepcopying here breaks ReverseDiff. See comment below:#1015 (comment)