Peter N Lewis wrote:
Another (non-portable) option, would be if we had the way of explicitly specifying "throw away the result" akin to C's (void) (which sadly is needed more and more for compatibility with the idiotic C calls that pointlessly return their parameter),
GPC supports `attribute (ignorable)' now on function declarations for exactly this purpose. But if you don't like (for aesthetic or MW compatibility reasons) to call such functions like procedures, you will need something else indeed. (And it doesn't help for unused parameters, either.)
then that could be used to accomplish this without a dummy variable, but would not solve the problem of source code compatibility, although it would change the location of the GPC macro and make it somewhat clearer and more consistent in location.
For example, if GPC supported a syntax like:
nil := whatever
Then that could be used to both throw away function results (but clearly mark them in the code which is exactly as safe as writing dummy_result := whatever) as well as provide a mechanism for "using" unused variables.
I agree with the semantics, but as you might remember, we had such a discussion, and I expressed my concerns about that syntax:
: `nil' is a constant, and it's of pointer type. This assignment would : violate both rules (and basically create a completely different : thing by the same name). I don't think we should follow the example : of some other languages to squeeze out the last bits of unused : syntax (usually accompanied by worse error recognition). : : What I could imagine is a built-in procedure `Ignore', : `IgnoreValue', `Discard' or so which takes one parameter of : arbitrary type and does nothing.
On 31 Dec 2003 I wrote:
: I already stated the problems I see with this syntax. Unlesss you : can address these concerns, just repeating the suggestion is quite : pointless.
After that mail the other thread seems to have ended, so I haven't done anything about it since then. Still I prefer such a built-in procedure.
BTW, is `nil := ...' MW syntax? Does MW support macros with arguments? If so, you could on the MW side define a macro `Discard (foo)' that expands to `nil := (foo)'.
Unfortunately, while I could probably define a macro like:
{$ifdef __GPC__} {$definec NOTUSED attribute(unused)} {$elsec} {$definec NOTUSED } {$endc}
and add the NOTUSED entries to my parameters, I cannot think of any way to get GPC to ignore or udnerstand the {$unused( param_name )}
Could $unused either be supported to disable the warning for a variable/parameter, or could we get some sort of flag to allow {$unused(x,y,z)} to be silently ignored so that it is possible to write code that is source compatible?
I don't really like this syntax, because (our) compiler directives usually don't refer directly to language elements (identifiers).
So I'd rather tend to ignore it -- perhaps ignore `{$unused...}' in Mac mode with a warning otherwise (or only if `-pedantic'?), just like we ignore several BP directives?
Ignoring it would be fine, preferably not only in Mac mode, it would need its own switch or pedantic would be fine by me (I don't generally use Mac mode as such even though it is Mac specific because I want to access the general GPC facilities in as GPC a manner as possible). Ignoring {$unused} should be safe for anything other than pedantic mode since other than leading to a possible source compatibility issue, it can't do any real damage since it only hides a warning and if it is ignored by GPC it will just mean the warning is displayed again...
OK. Do we still need this if we add `Discard'?
The original problem was to support specifying parameters as unused in a way that is source code compatible between MW and GPC. As I sated, I can specify a parameter as being unused in GPC using "attribute ( unused);" and use a define that expands to "attribute ( unused );" in GPC and nothing in MW. But I can only do this in MW by using {$unused(paramname)} which I cannot "hide" from GPC since I can't use a macro to expand to a pragma.
BTW, a future GPC version might allow macros that expand to compiler-directives, but AFAICS this wouldn't help here since you'd need this on the MW side where it apparently isn't possible.
Frank