That last one requires a different sequence of llvm instructions than the other examples (it's the difference between isbits and bitstype). Not hard, but likely unimplemented. On Mon, Feb 9, 2015 at 2:57 PM Simon Danisch <[email protected]> wrote:
> While we're at it... > Why does this work: > > reinterpret(Float32, Int32(0)) > @assert isbits(ImmutableType1) && isbits(ImmutableType2) && > (sizeof(ImmutableType1) == sizeof(ImmutableType2)) > reinterpret(ImmutableType1, Array(ImmutableType2, 42)) > > but this does not: > > reinterpret(ImmutableType1, ImmutableType2(...)) > > Am Sonntag, 8. Februar 2015 21:35:20 UTC+1 schrieb [email protected]: > >> I would like to request the following language feature: a function or >> macro to modify a field of an immutable inside a container. Consider: >> > >> immutable T >> fielda::Int >> fieldb::Int >> fieldc::Int >> end >> >> function modify_fieldc!(x::Array{T,1}, sub::Int, newc::Int) >> x[sub] = T(x[sub].fielda, x[sub].fieldb, newc) >> end >> >> This function modifies one field of an immutable object that sits inside >> a container. The above construct, namely: >> x[sub] = T(x[sub].field1, x[sub].field2, ... , newval, ... >> x[sub].fieldn) >> occurs rather frequently in my code. It is not very readable and is also >> fragile in the case that I modify my code and put more fields in T later. >> It would be much nicer if there were a universal function like this: >> modifyField!(x, sub, fieldc, newc) >> >> Note that I declared T to be 'immutable' rather than 'type' for >> performance reasons-- I prefer the data in the array x to be packed in >> memory rather than accessed with pointers. If T were a 'type' then >> obviously the problem would go away. >> >> Maybe it is already possible to write a function or macro for this >> purpose in the existing language? >> >> Thanks, >> Steve Vavasis >> >>
