r.expr({a: 1}).merge([1,2,3])

[neumino]

I accidently run something like:

r.expr({a: 1}).merge([1,2,3])

And it returns [1,2,3].

I would expect an error.

[coffeemug]

This definitely seems like a bug. Also note:

> r.expr({a:1}).merge(1)
1

@mlucy -- is this actually a bug or intended behavior? I'd like to hear what you think before we fix this (in case this was by design for a reason that doesn't come to mind).

[Tryneus]

datum_t::merge will always return the right-hand side in the case that not all arguments are objects. Not sure if this is intended, but it's pretty explicitly there in the code. Note that if we do change this, we'll need old and new version-handling for it.

[mlucy]

I think that was the original intended behavior, but I would be fine with changing it. Re-tagging as a ReQL proposal and putting into subsequent in case anyone can remember a good reason why we wanted to do it that way.

[timmaxw]

r.expr({key:{a:1}}).merge({key:[1,2,3]}) should obviously return {key:[1,2,3]}. The current behavior can be seen as a generalization of that to the case where the nesting level is zero. I speculate that that was the original reason. I would also be fine with changing it.

[mlucy]

I can see why it's confusing, though, because:

• r({a: {b: 1}}).merge({a: 2}) => {a: 2}
• r({b: 1}).merge(2) => 2
• r({a: 1}).merge({a: 2}) => {a: 2}
• r(1).merge(2) => ERROR

[danielmewes]

This seems to be the same as #2270

[mlucy]

I'm actually not so sure we should change this any more. I think instead we should maybe make r(1).merge(2) return 2.

[danielmewes]

Sorry for realizing this only after you'd already commented, but I'm actually going to move this to subsequent as well (i.e. out of the 2.1 discussion period).