Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: New directions in C: Default arguments Date: Mon, 16 Mar 2015 11:36:15 -0700 Organization: None to speak of Lines: 72 Message-ID: <877fug23j4.fsf@kst-u.example.com> References: <82a53e52-cab0-491c-a593-ef36869419c3@googlegroups.com> <87mw3eo636.fsf@bsb.me.uk> <29c12da8-bb4f-482d-9266-5f51270d7579@googlegroups.com> <329f010e-821d-4c60-813a-949094e6e3be@googlegroups.com> <8953aa43-c9e1-471e-a763-c0d4c7fcc43b@googlegroups.com> <3f5b38ce-dd98-4ba6-b7a7-0ab9e8b89d44@googlegroups.com> <14f98f84-8033-4b26-ada1-305d89491e7e@googlegroups.com> <87mw3d0xcl.fsf@kst-u.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="c77ff4d35e33d1c939d3461ebde8dd0d"; logging-data="17960"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18apA/lmYjjQofh4ZcU91xD" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:V/fDUTKPJOA0nf9DsJuD+8own5U= sha1:p9Tzmd+dP1Qsqwj8LPqd294nrgA= Xref: csiph.com comp.lang.c:58237 David Brown writes: > On 16/03/15 16:35, Keith Thompson wrote: [...] >> One problem with keyword parameters is that C doesn't require consistent >> parameter names in all declarations. Parameter names are not part of >> the "signature" of a function (because in current C they're irrelevant >> to the caller). >> >> For example, given a definition like: >> >> void func(int x, int y) { /* ... */ } >> >> any of these declarations would be compatible: >> >> void func(int, int); >> void func(int x, int y); >> void func(int y, int x); >> >> Probably the simplest rule (that would not break existing code) would be >> to make named parameters consistent with the most recent visible >> declaration. > > That's a simple rule, and means there is no longer any problem. The > only conceivable alternative is to insist that declarations are > consistent - while I think that would be a great thing, it would break > existing code to no useful purpose. It would therefore be a fine > optional warning feature for a compiler, but should not be part of the > language. I wouldn't say that there's "no longer any problem". In current C, the parameter names are meaningless. The C standard presents the declaration of the fopen() function as: FILE *fopen(const char * restrict filename, const char * restrict mode); but the implementation I use has: extern FILE *fopen (const char *__restrict __filename, const char *__restrict __modes) ; which is perfectly valid. Even if I had a compiler that supports named parameters, I couldn't write: FILE *f = fopen(.filename = "foo.txt", .modes = "r"); Supporting named parameters in portable code would require library providers to declare parameters consistently. With this approach, it would be many years before all implementations are updated to use consistent parameter names, and code that uses the standard names would fail to compile under some implementations. The standard library would be bad enough; other libraries could be worse. I had been thinking that matching the most recent visible declaration would be the best approach, but now I'm thinking that *if* named parameters were to be added to the language, we'd need to add a rule requiring names to be defined consistently. (Presumably if C had had named parameters from the beginning, this rule would already have been in place.) Having two visible declarations that use different names would become a constraint violation. A declaration that doesn't provide parameter names would mean you couldn't used named parameters when calling it (or, perhaps, would no longer be permitted). -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"