ability to mark fields of types as immutable-const

[goretkin]

(Julia Version 0.3.4-pre+47)
I should know better than to even be attempting what I was attempting, but perhaps something loud should happen if a user tries to set the .parameters field of a DataType object.

julia> type A{T}
           a::T
       end

julia> A(1)
A{Int64}(1)

julia> A(1.0)
A{Float64}(1.0)

julia> A(1.0f0)
A{Float32}(1.0f0)

julia> A("hello")
A{ASCIIString}("hello")

julia> typeof(A(1)).parameters = (Float64,)
(Float64,)

julia> typeof(A("hello")).parameters = (Int,)
(Int64,)

julia> A(2)
A{Float64}(2) #hm

julia> A("hello")
A{Int64}("hello") #hmm

julia> ans.a
"hello"

[vtjnash]

this is a specific case of wanting the ability to mark specific fields of a type as being constant (also helps type inference in many places).

also related: #6713

[JeffBezanson]

Another approach is to make specific fields of an immutable mutable by wrapping them in some kind of box. @vtjnash should we use RefValue for this, or do we need another type?

[vtjnash]

yes. and that would be equivalent to the approach taken by the codegen when creating a closure environment (we can replace Box with Ref{inferred type})

I think the real value in this change is that we could merge the isbits and immutable distinction. Then the immutable property would directly set whether a type was inlined or not, regardless of its contents.

[JeffBezanson]

isbits would still be needed to distinguish pointers from plain data.
RefValue is a bit verbose for this purpose. Maybe we should merge it with the Box type. The way closures are lowered is due for an overhaul anyway.

[bramtayl]

struct A
    a::Int
    mutable b::Int
end

seems like a very simple syntax for this, and is backwards compatible to boot.

[bramtayl]

Seems like a relatively minor change that could potentially lead to big performance increases.

[StefanKarpinski]

I don't think that's quite right. If any field of a struct is mutable, then you can no longer copy it around freely, so even one mutable field poisons the whole thing and forces the structure to behave as if it has a stable memory address, i.e. like a mutable struct. The other direction is the one which is fairly straightforward: a mutable struct with some const fields is a simple matter of not allowing modification of those fields; it still needs a stable memory address, but that's what someone would expect based on the fact that it's still declared as a mutable struct.

[StefanKarpinski]

We could make a struct with some mutable fields behave as if those fields were actually Ref fields and make the getters and setters for those fields automatically dereference the Ref boxes, but that's not so simple anymore.

[bramtayl]

We could make a struct with some mutable fields behave as if those fields were actually Ref fields and make the getters and setters for those fields automatically dereference the Ref boxes

a mutable struct with some const fields is a simple matter of not allowing modification of those fields

Can we have both? Could Julia use some heuristic to decide which strategy is most likely to increase performance? You can pretty easily translate one to the other, and they both have the same semantics, I think, except for the memory address bit.

[vtjnash]

We could, but if you need a stable address for part of it, it's likely to always be much cheaper and faster to get one stable address for the whole thing, than to essentially carry around multiple very fat pointers to a the mutable fields.

[bramtayl]

I think it might just be a matter of documenting that tradeoff, then? Unless I'm misunderstanding.

[DilumAluthge]

@vtjnash Now that #43305 has been merged, has this issue been resolved?