Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Which code style do you prefer the most?
Date: Sun, 2 Mar 2025 19:04:04 +0100
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <vq26ik$sjm7$1@dont-email.me>
References: <vpkmq0$21php$1@dont-email.me> <vpl62m$250af$1@dont-email.me>
 <87frk10w51.fsf@onesoftnet.eu.org> <vpn8vs$2jmv1$1@dont-email.me>
 <vpn92i$86q$1@reader1.panix.com> <vpodnf$2q6ak$4@dont-email.me>
 <vpovd0$30d00$1@dont-email.me> <vpp011$30evb$1@dont-email.me>
 <vpp8ag$31ooi$1@dont-email.me> <vppaeq$323aa$1@dont-email.me>
 <vprpss$3ipmu$1@dont-email.me> <vprtlj$3jdn5$1@dont-email.me>
 <vprv75$3jmqu$1@dont-email.me> <vps2k5$3k722$1@dont-email.me>
 <vpt8ju$3r2n0$6@dont-email.me> <vpvcrm$9uaj$2@dont-email.me>
 <vpvqtt$ckvi$1@dont-email.me> <vq017i$dkuj$2@dont-email.me>
 <vq02is$duht$1@dont-email.me> <87o6ykw7f9.fsf@nosuchdomain.example.com>
 <vq1gpk$ou5h$1@dont-email.me> <vq1n82$pskj$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 02 Mar 2025 19:04:07 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e34113db79e89efb1cf30712b20c3094";
	logging-data="937671"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19IxHKEhn4EV2rZwS4+Fs0En5YtnwUhZp0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:H1IVLxEBbTlhyOBiQHbk4xn+pic=
Content-Language: en-GB
In-Reply-To: <vq1n82$pskj$1@dont-email.me>
Bytes: 5712

On 02/03/2025 14:42, bart wrote:
> On 02/03/2025 11:52, David Brown wrote:
>> On 02/03/2025 02:24, Keith Thompson wrote:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>> On 01.03.2025 23:20, Lawrence D'Oliveiro wrote:
>>>>> On Sat, 1 Mar 2025 21:32:59 +0100, Janis Papanagnou wrote:
>>>>>> My guess is that this form is just an informal syntax mimicking 
>>>>>> Perl's
>>>>>> function parameter passing ...
>>>>>
>>>>> The idea of passing arguments by keyword predates Perl.
>>>>
>>>> That wouldn't surprise me. - I know it from Perl. - Which other
>>>> (earlier) languages do you have in mind? - What's its origin?
>>>
>>> For example, it exists in Ada since 1983.  The following are all
>>> equivalent, given that Foo takes integer arguments Arg1 and Arg2:
>>>
>>>      Foo(Arg1 => 10, Arg2 => 20);
>>>      Foo(Arg2 => 20, Arg1 => 10);
>>>      Foo(10, Arg2 => 20);
>>>      Foo(10, 20);
>>>
>>> The syntax is IMHO much nicer than using /*...*/ comments in C.
>>>
>>
>> Ada (and Python - no idea about Perl) named parameter passing have two 
>> huge advantages over comments like Lawrence uses - one is that they 
>> let you order the parameters in what you see as a logical manner at 
>> the call source (especially useful combined with default parameters), 
>> and the other is that the whole thing is checked by the compiler.  If 
>> the function's signature is changed, parameters re-ordered or renamed, 
>> the call source is either still correct or there is a hard 
>> compile-time error.  With comment-based naming, all you have done is 
>> guaranteed that the call source looks correct but is wrong.  Using 
>> comments like Lawrence does is significant extra effort (especially to 
>> keep it in sync with changes), and can't be trusted.  It's all cost 
>> and no gain.
>>
>> Named parameters are a useful tool when the language provides them, 
>> but useless when done with comments.
>>
>> If someone wants to have the benefits of named parameter passing in C, 
>> then using a struct for the arguments along with designated 
>> initialisers and compound literals is a much better way.  Individual 
>> types for the different parameters also works (wrapping the desired 
>> types in structs).
> I've seen examples of emulating named parameters in C using structs. 
> They had multiple issues:
> 
> * Having to invent auxiliary struct types for each kind of function 
> signature
> 
> * Having to rewrite function bodies to access parameters as struct 
> elements instead
> 
> * (Within the implementation, probably having to set up then copy the 
> struct to preserve value-passing semantics)
> 
> * At the call-site, needing to use an ugly, cluttered syntax involving 
> compound literals and designated initialisers, a lot worse than the 
> example with /**/ comments
> 
> * Being limited in the default values for omitted arguments, which can 
> only be zeros
> 
> * Not being able to superimpose named parameters on imported functions 
> of existings libraries, since they require the function source code to 
> be revised and recompiled. (In my implementations of the feature, this 
> is possible, while none of the above drawbacks apply.)
> 

Sure.

But despite all that, it is still better than an obsessive use of 
comments in the form Lawrence uses (or promotes) - at least mistakes and 
inconsistencies are caught at compile-time.

And the alternative I gave - using individual struct wrappers for each 
parameter - has related disadvantages.  (It's a good deal less bad in 
C++ than in C, but still not nearly as nice as real named parameters 
would be.)

> It's better to accept that the language doesn't have the feature.
> 

Agreed.

> However, it is similar to designated initialisers, and would have been a 
> much more useful feature for C99.

I'd like to see named function parameters as part of C.  But I'm not 
holding my breath waiting for them!