Skip to content

Commit

Permalink
add deprecations for some removed copy methods
Browse files Browse the repository at this point in the history
ref #15675
  • Loading branch information
JeffBezanson committed Apr 26, 2016
1 parent 893f7e3 commit 063ef32
Showing 1 changed file with 3 additions and 0 deletions.
3 changes: 3 additions & 0 deletions base/deprecated.jl
Original file line number Diff line number Diff line change
Expand Up @@ -1075,6 +1075,9 @@ end
# #4163
@deprecate xdump dump

@deprecate copy(x::AbstractString) identity(x)
@deprecate copy(x::Tuple) identity(x)

# During the 0.5 development cycle, do not add any deprecations below this line
# To be deprecated in 0.6

Expand Down

5 comments on commit 063ef32

@Keno
Copy link
Member

@Keno Keno commented on 063ef32 Apr 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DWARF.jl has a variable which is either a Tuple (register, offset pair) or an array (DWARF expression). It is somewhat annoying that I can't just copy that variable.

@JeffBezanson
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really get this --- if you're copying it, presumably you're mutating it at some point. But tuples can't be mutated, so those cases are already split somehow. What am I missing?

@Keno
Copy link
Member

@Keno Keno commented on 063ef32 Apr 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's something like

type State
cfa
states
end
function dosomestuff(state1, state2)
state1.cfa = copy(state2.cfa)
state1.states = copy(state2.states)
end
address = isa(cfa, Tuple) ? get_value(cfa[1]) + cfa[2] : evaluate_expression!(cfa)

where evaluate_expression! could potentially mutate. It doesn't at the moment (so I removed the copy), but it quite reasonably could.

@Keno
Copy link
Member

@Keno Keno commented on 063ef32 Apr 27, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The point is that most of the time it doesn't matter whether it's a register/offset pair (you still move them around just the same). Only when you evaluate it do you care.

@JeffBezanson
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems quite possible to structure that so that calling copy on a tuple isn't actually needed, especially since there is already an isa check somewhere in the code. I find it kind of obfuscated to call copy on something and have it be a no-op.

In my view copy is part of a mutable collections API. If not, then what is it? Should we have copy(x) = x? In languages with both mutable and immutable collections, I believe it's most common not to provide copy for immutable collections.

Please sign in to comment.