Define Base.copy for ::AbstractTime

[mbauman]

This comes up when specifying the plot bounds in Dates (e.g., in GiovineItalia/Gadfly.jl#354). I suppose defining this for all ::AbstractTime is a little dangerous as others could define their own mutable subtypes. I could easily change this into a large union if desired. But I think, in general, there should be a copy method for these types, no?

[mbauman]

cc @quinnj

[ivarne]

Why don't we have a generic fallback copy function? Just noop for immutable and constructing a new object with the same properties for types.

[quinnj]

I was wondering that myself.

[JeffBezanson]

We could use staged functions to write really efficient fallbacks for copy and == (e.g. #4648).

[ivarne]

+1 for efficient fallbacks

Could staged functions be used to make a generic deepcopy that work without a dict in the cases where no self-referential is possible?

[mbauman]

Why don't we have a generic fallback copy function? Just noop for immutable and constructing a new object with the same properties for types.

Can we assume that all user-defined types have the default constructor (or something with an equivalent signature and functionality)? Otherwise I don't know how to generically construct a type. I've not played with stagedfunctions much, but this seems to do the trick.

julia> stagedfunction Base.copy(x)
         if !x.mutable & x.pointerfree # Should only pointerfree immutables be no-ops?
           :x
         else
           args = map(fld->:(copy(x.$fld)), x.names) # Edit: this approach wouldn't allow for circular references
           Expr(:call, x, args...)
         end
       end

[ivarne]

I think we can should require a suitable default constructor for the default copy to work.

[mbauman]

I'm not sure how you'd handle circular references to the object within its fields, though. I suppose we could do the Matlab thing and require all types to have a zero-argument constructor function (ducks).

[ivarne]

The efficient deepcopy would only work when the type's fields is fully typed (eg. bits-types and arrays of those), so that we can statically determine that no cycles are possible.
Sorry didn't understand.

[ivarne]

The default copy can fail (with a recommendation to use deepcopy) if one of the types fields can't be proven (statically) to not contain cycles. There might also be an argument that we shouldn't make copies of the fields in the first place, as this is consistent with the array behavior.

[mbauman]

Right. Of course. This will recurse. I didn't think about this very clearly. Going by the help text ("outer structure is copied") and the Dict/Array implementations of copy, it seemed like the fields should get copied… but I guess that will be dependent upon the data structure, and so the generic copy should probably be conservative.