From: Johannes Sixt <j6t@kdbg.org>
Date: Mon, 10 Jul 2017 21:11:35 GMT
Subject: Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT
Message-ID: <962da692-8874-191c-59d4-65b9562cf87f@kdbg.org>
In-Reply-To: <xmqq4luk58ot.fsf@gitster.mtv.corp.google.com>

Am 10.07.2017 um 22:38 schrieb Junio C Hamano:
> Johannes Sixt <j6t@kdbg.org> writes:
> 
>> It's a pity, though, that you do not suggest something even more
>> useful, such as C++14.
> 
> I cannot tell if this part is tongue-in-cheek (especially the "++"),
> so I will ignore it to avoid wasting time.

Actually, I'm serious.

>>> Subject: [PATCH] strbuf: use designated initializers in STRBUF_INIT
>>
>>> -#define STRBUF_INIT  { 0, 0, strbuf_slopbuf }
>>> +#define STRBUF_INIT  { .alloc = 0, .len = 0, .buf = strbuf_slopbuf }
>>
>> While this may serve as a test balloon, changing STRBUF_INIT, or any
>> of those _INIT macros, is actually the least interesting. The
>> interesting instances are initializations for which we do *not* have a
>> macro.
> 
> I am not sure what negative impact you think the macro-ness would
> have to the validity of the result from this test balloon.  An old
> compiler that does not understand designated initializer syntax
> would fail to compile both the same way, no?
> 
> 	struct strbuf buf0 = STRBUF_INIT;
> 	struct strbuf buf1 = { .alloc = 0, .len = 0, .buf = strbuf_slopbuf };

I said it is uninteresting, not that there is a negative impact. There 
is simply nothing gained for strbuf users: They would use STRBUF_INIT 
before and after the change and would not benefit from designated 
initializers.

This change may serve well as a test balloon, but not as an example of 
the sort of changes that we would want to see later (of the kind "change 
FOO_INIT macro to use designated initializers"; they are just code churn).

-- Hannes