bool values are not merged properly about mergo HOT 7 CLOSED

@lakhgupt @anderssonw @designtesbrot @mdelapenya @vedhavyas @beauso @erikreinert dest.C has false value, and src.C has true value. According to the documentation:

Mergo merges same-type structs and maps by setting default values in zero-value fields.

false is the zero value for booleans:

When storage is allocated for a variable, either through a declaration or a call of new, or when a new value is created, either through a composite literal or a call of make, and no explicit initialization is provided, the variable or value is given a default value. Each element of such a variable or value is set to the zero value for its type: false for booleans, 0 for numeric types, "" for strings, and nil for pointers, functions, interfaces, slices, channels, and maps.

The example is coherent with the stated behaviour.

About overwriting - assuming no mergo.WithOverwrite is used - I didn't reproduce it using the playground example by switching dest.C and src.C (so dest.C is already true):

package main

import (
	"fmt"

	"dario.cat/mergo"
)

type Foo struct {
	A string
	B int64
	C bool
	D int64
}

func main() {
	src := Foo{
		A: "five",
		B: 5,
		C: false,
		D: 10,
	}
	dest := Foo{
		C: true,
		B: 3,
		D: 11,
	}
	mergo.Merge(&dest, src)
	fmt.Println(src)
	fmt.Println(dest)
}

// Output:
// {five 5 false 10}
// {five 3 true 11}

from mergo.

I'm seeing this issue, any thoughts on why this is happeneing ?

from mergo.

fyi, just reproduced this too.

from mergo.

Also recently noticed this. I might have expected false -> true overwriting, but we have true -> false overwriting which is definitely not the expected behaviour.

from mergo.

@darccio This is not what we experienced, the code block you mention is expected, but irrelevant. We were given true -> false, when the src had a non-zero field, which does not coincide with the expected behaviour. Unless something has been done to circumvent this, please re-open the issue.

from mergo.

@anderssonw Please provide and example. The library is simple enough and there are no more foreseeable ways that can lead to the described issue.

If I can't reproduce it, I can't fix it.

from mergo.

Luckily it seems I was mistaken in our case :)

We updated the destination struct by mistakenly having both the source and destination refer to a single struct called cron, when the sources cron was update, so was of course the destination, leading to me thinking it was mergo. Thanks for rubber ducking I guess 😅

from mergo.