On Tue, Aug 5, 2014 at 7:01 PM, <[email protected]> wrote: > Stefan. > > Could you give me an example of how my proposal to separate the two > attributes of immutable would undermine generic programming? I'm not > seeing the issue. > > Thanks, > Steve >
Let's pretend that Julia had both reference and value types: abstract A reftype R <: A field end valtype V <: A field end function foo(x::A, v) x.field = v return x end Given x::A, what does this code do?: y = foo(x, 2); x.field == y.field You can't tell unless you know whether the type of x is a reference type or a value type. If typeof(x) == R, the result is true, if typeof(x) == V, it's false. Considering the definition of the function foo by itself, you have no idea what it does unless you know what kind of value it gets applied to. Applied to a reference typed object, it mutates its argument and then returns it; applied to a value typed object, it copies its argument and returns a mutated copy. Those are rather different behaviors. If you want generic functions that works alike for reference types and value types, you can write code that behaves the same for both. In fact, there's a very simple restriction that accomplishes this: don't use mutation. Without mutation, value types and reference types are indistinguishable. Perhaps you can see where this is going...
