Re: [PATCH 00/12] c99: use more designated initializers

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 24, 2022, 22:43 UTC
Message-ID: <220224.86y21z98zr.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqqsfs8kpm4.fsf@gitster.g>

On Thu, Feb 24 2022, Junio C Hamano wrote:

Show 24 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> This is probably a bit premature given that we still are treating the
>> C99-isms as weather balloons. The idea was to keep things in an
>> easily-revertable state for at least a couple of major versions.
>>
>> The referenced changes are only in core Git as of v2.34.0, and we are not
>> even half-way through the v2.36.0 cycle.
>
> The proposed commit log messages need updating.  By refering to much
> newer commits created by the same author, instead of the beginning
> of the official weather balloon experiments, it created an unnecessary
> confusion.
>
> Read the CodingGuidelines document.  Everybody knows what it says by
> heart by now, right? ;-)
>
>    . since mid 2017 with cbc0f81d, we have been using designated
>      initializers for struct (e.g. "struct t v = { .val = 'a' };").
>
>    . since mid 2017 with 512f41cf, we have been using designated
>      initializers for array (e.g. "int array[10] = { [5] = 2 }").
>
> I do not think doing this in early 2022 is still premature.

It's hard sometimes to anticipate what'll be the best reference. I figured linking to similar recent tree-wide changes would make it easier for reviewers to shortcut to "oh, we had similar tree-wide changes recently, so this is OK too".

As opposed to referencing the initial forays into designated initializers, which wouldn't provide the same overview of how tree-wide this pattern already is at a glance.

But sure, I can mention that more prominently/discuss both.

> I hate to having to deal with such a tree-wide churn, though.  I'd
> rather see "let's do this only on quiescent part of the tree a small
> bit at a time" like on imap-send.c but not involving anything known
> to be actively touched, like ref backends.

While these are tree-wide, I don't think you'll have any trouble with them, including the ones touching the refs backend.

We're anticipating the final bits of the reftable integration, which will add another declaration like the one in 2/12, but that won't conflict with these modifications of the existing assignment.

Of course such a change might also want to use designated initializers to match, but that would have been a good idea anyway for new code regardless of whether this series got merged or not.