Open hiiamboris opened 3 years ago
The object copy
does not seem consistent with copy
on series:
>> a: "string"
== "string"
>> b: next a
== "tring"
>> head copy b
== "tring"
So the make
behavior should be privileged then, as it is more consistent with overall copy
semantics.
I disagree. copy
and copy/deep
are consistent:
>> o: object [s: next "1234"]
>> p: copy o
>> q: copy/deep o
>> head p/s
== "1234"
>> same? p/s o/s
== true
>> head q/s
== "234"
>> b: reduce [next "1234"]
== ["234"]
>> c: copy b
>> d: copy/deep b
>> head c/1
== "1234"
>> same? b/1 c/1
== true
>> head d/1
== "234"
make
behavior seems less useful. This is what I hit in my https://gitlab.com/-/snippets/2066140 experiment.
I needed a copy of this object:
object [
width: either pair? size [size/x][0]
part: none
data: make [] either pair? size [size/y * size/x][size]
]
But with width
field changed, and data
remaining the same. make old [width: new]
looked like obvious solution but it didn't work, so I had to copy
it. Current make
seems to work like copy/deep
, whereas in Rebol it worked like copy
.
OTOH if we look into the series inside function bodies https://github.com/red/red/issues/4533 https://github.com/red/red/issues/4523 that's quite a design question how to make it all consistent and still useful...
Describe the bug
Inner series are copied differently:
In R2 & R3 the behavior of
make
follows thecopy
scenario above.Expected behavior
I prefer
copy
scenario as it is less surprising and is lossless, while aftermake
any logic that relied on changed index becomes broken.Platform version
Related: https://github.com/red/red/issues/4533 https://github.com/red/red/issues/4523