Frank Heckenbach wrote:
Now, a local "no-unused-warnings" options would be finer-grained than `W-', but still not as much as possible. For one thing, it concerns all parameters. One can imagine a fixed parameter form where some parameters are always needed, and some are "optional", so you do want warnings if you don't used the required parameters.
It depends on the implementation, it could be as fine-grained as we want it to be. So, if we need control over individual parameters, local warning directives could be put in the header around individual parameters.
Another thing, you'd have to enclose the whole routine (not just the header) with this option since the fact that parameters are unused turns out at the end of the routine (unless you put the directive around the final `end;' or such which also obscures the matter).
That would indeed obscure the matter. What I like about Pascal is writing software that achieves the highest possible degree of transparency and translucency. A Pascal algorithm shouldn't be a bunch of tricks but an elegant expression of clear logical ideas. So, in this case, if we want the advantages of unused-parameter checking, we need a way to say "hey, this is a routine with unused parameters" or "hey, this parameter is unused". That information belongs in the header, not in the body. Next, it is a matter of compiler implementation to use that information to do the actual unused-parameter check in the body (or not). The compiler could/should remember all information specified in the header, including compiler directives.
However, using a trick in the body to make an unused-parameter look like a used parameter obscures the matter. It has nothing to do with the logic of the actual algorithm which dictates that the parameter is *not* used. So any statement in the body that specifies otherwise (to make the warning go away) obscures the matter. I call that upside-down thinking.
But then it affects also subroutines which generally don't have the same fixed parameter form, so you want warnings there.
This is no longer a problem if local warning directives can be specified in the header.
Now, to the case of unused parameters - they don't hurt, unused parameters won't crash software.
Crashing is not the only kind of bug.
OK.
But - apparently we missed an opportunity to eliminate the unused parameter to make the software faster (at least in theory). However, this leads to problems when the parameter list of a procedure or function can not be changed, as is the case with e.g. callback routines. For those routines, we can should be able to put the check off with {$local W no-unused-parameter} ... {$endlocal}.
That's all - sorry, I don't see why need need control over individual parameters.
I'd prefer to.
OK.
In addition, since I sometimes want to discard other values (function results), it might be preferable to do both things with a common syntax.
Discarding a mechanical result value, actually returned by a function, is something completely different from the logical specification of an unused parameter. Nothing is discarded in the latter case. It only looks like we are discarding something once we take the (strange) decision to reference an "unused" parameter without actually using it. In other words, we then need a way to "use" a parameter it without "using" it, which brings us to the idea of "discarding" it. Sorry if I sound a bit sharp.
Regards,
Adriaan van Os