Decode does not zero the destination variable before decoding the value into it.

[curioustolearn]

I realized today that Decode does not zero the destination variable before decoding the value into it. Is this expected; or is this a bug?

Example:

	var rec r.ChangeResponse
	var updatedDec UserDecision

      	go func() {
		for cur.Next(&rec) {
			newValInterface := rec.NewValue
			fmt.Printf("\nNewvalue: %+v\n", newValInterface)
			fmt.Printf("\nupdatedDec: %+v\n", updatedDec) 
			mapstructure.Decode(newValInterface, &updatedDec) 
			fmt.Printf("\nDecision update: %+v\n", updatedDec)
			decUpdateCh <- updatedDec
		}
		log.Println("Exiting goroutine listening on decUpdate changes.")
	}()

In the above example updatedDec is not zeroed across iterations. updatedDec contains an array. If that array has more elements than the same array in the new value, then some of the earlier values remain in there after mapstrucure.Decode.

[mitchellh]

Yes this is done on purpose so that you can call Decode multiple times to "build up" a result.

Arrays/slices in particular this may not make sense though.

[curioustolearn]

Thanks. I will remember to zero them before the new iteration.

[mitchellh]

I do think the slice/array should be zeroed though (hence me not closing this issue). I'm thinking about it more though.

[curioustolearn]

Yes, I agree. In the case some input is helpful: I think currently it replaces the existing elements in the slice with new elements. This works as long as the new slice is the same length or bigger than the existing slice. This, however, results in a problem when the new slice is smaller than the existing slice, since some of (but not all) previous elements are left in the slice.

[nd2s]

Is there a solution/workaround yet? I'd need slices to be zeroed before values are written into (but only if this field should be updated/values are set).

[nd2s]

Any more thoughts on this? In my opinion probably everyone expects an array/slice to be zeroed before update... Partial update of an array seems to be a very rare edge case.

[yashtewari]

I agree that arrays/slices should be fully replaced when decoding... I think this would be expected behavior for most users, which could make them unknowingly introduce bugs into their systems (as I did). What are some arguments for keeping things the way they are?

I'm willing to put up a PR for this.

[klesh]

😂 I find myself falling into the same hole as well. We rely on the feature to implement a bunch of PATCH APIs and they worked nicely for years until I tried to reduce one of the fields with the list type a week ago.

I wonder what is the use case of "Merging List"? How about strings because they could be perceived as a list of characters?
If it has to be the default behavior, can we have an option to disable it?

I agree that arrays/slices should be fully replaced when decoding... I think this would be expected behavior for most users, which could make them unknowingly introduce bugs into their systems (as I did). What are some arguments for keeping things the way they are?

I'm willing to put up a PR for this.