Re: [PATCH v2 2/8] object-store-ll.h: add note about designated initializers

[Junio C Hamano <gitster@pobox.com>]

Taylor Blau <me@ttaylorr.com> writes:

> @@ -337,6 +337,14 @@ struct object_info {
>  /*
>   * Initializer for a "struct object_info" that wants no items. You may
>   * also memset() the memory to all-zeroes.
> + *
> + * NOTE: callers expect the initial value of an object_info struct to
> + * be zero'd out. Designated initializers like
> + *
> + *     struct object_info oi = { .sizep = &sz };
> + *
> + * depend on this behavior, so consider strongly before adding new
> + * fields that have a non-zero default value.
>   */
>  #define OBJECT_INFO_INIT { 0 }

Hmph, after thinking hard enough, if a developer cannot come up with
a way to avoid non-zero default value, the callers could just work
if they instead did

	struct object_info oi = OBJECT_INFO_INIT;
        oi.sizep = &sz;

and the member of non-zero default value can be delat with by
updating the default initializer, perhaps like

	#define OBJECT_INFO_INIT { .enabled = 1 }

So I am not sure how the advice in the new comment really helps the
intended audiences.  Shouldn't the advice be more like

    NOTE: when a structure foo has FOO_INIT macro to initialize,
    *never* use your own initialization like so:

	struct foo foo_instance = { .member_i_care_about = 13 };

    Instead, use the _INIT macro and then assign to the member you
    care about, like so:

	struct foo foo_instance = FOO_INIT;
	foo_instance.member_i_care_about = 13;

    This is because there may be members of "struct foo" whose
    default value is not zero, or there will later be added such
    members to the structure.

perhaps?

I can buy a counter-proposal that does not forbid a custom
designated initializers that depends on "all zero" default IF it
gives a piece of advice to the readers that is more usable than
"consider strongly before adding", as "consider strongly before
adding" there smells like just an euphemism for "never add", though.

Thanks.