std.objectRemoveKey does not return consistent results between Go an C version

[Duologic]

$ jsonnet --version
Jsonnet commandline interpreter (Go implementation) v0.21.0
$ jsonnet -e 'std.objectRemoveKey({ hello: "playground", hidden:: "yes" }, "hello").hidden'
"yes"

$ cjsonnet --version
Jsonnet commandline interpreter v0.21.0
$ cjsonnet -e 'std.objectRemoveKey({ hello: "playground", hidden:: "yes" }, "hello").hidden'
RUNTIME ERROR: field does not exist: hidden
        <cmdline>:1:1-77

Given the stdlib function in C's stdlib/std.jsonnet doesn't take hidden fields into account this is kinda expected. Should this be a bug here or in the C version?

[johnbartholomew]

Should this be a bug here or in the C version?

Do you have an opinion on it? Were you trying to do something in particular when you encountered this, and if so which behaviour do you need for your use-case?

@rohitjangid Any comments on this design question? Do you remember what your original use-case was and whether it matters for that case whether hidden fields are dropped or not?

---

Just reading the very short description of std.objectRemoveKey in the docs ("Returns a new object after removing the given key from object.") I would expect that hidden fields would be retained in the returned copy of the object. Hidden fields are retained when you inherit from an object, and std.objectRemoveKey (as a function which returns a 'modified version' of the object) could be thought of similarly to inheritance.

I may be missing something but I can't think of a way just using language primitives to 'copy' / inherit-from an object while removing a field. You can set a field to null, or you can hide a field, but that doesn't actually remove it. Not clear to me whether there are many cases where that distinction matters in practice. To me, that also suggests that std.objectRemoveKey (if it's useful at all!) should follow the Go implementation, in order to provide functionality that can only be provided by a builtin.

[rohitjangid]

@johnbartholomew Yeah hidden field should be included as is if they are not removed. There might be bug in cpp implementation of this function.