On Tue, May 14, 2019 at 02:57:01PM +0200, Johannes Schindelin wrote: > > But the parameter treated as a constant without getting modified > > during the invocation of the function is an implementation detail of > > the function; there is no point exposing that implementation detail > > to its callers. It does not even help the compilers handling the > > caller's compilation unit---the parameter is passed by value, so the > > caller knows that the callee would not modify it without "const" > > there. > > > > Does the language even allow flagging "const int in the definition, > > int in the declaration" as a warning-worthy discrepancy? > > Apparently it does, as MS Visual C does issue a warning (and with `/Wall`, > it fails). > > In any case, I don't think that it makes sense to have a function > declaration whose signature differs from the definition's. I actually agree with Junio's point that in an ideal world the declaration should omit details that are not relevant to the caller. But clearly we do not live in that world, and this is a small enough point that we should fix it in one direction or the other. I do have a slight preference for going the _other_ way. There is no need to mark the parameter as const in the definition. It is passed by value, so nobody except the function body cares either way. And we have many function bodies where value-passed parameters (or local variables!) are not marked as const, even though they are only assigned to once. I don't think that annotation is telling much to any reader of the code, nor to a decent optimizing compiler. -Peff
