You mean people would feel forced to leave out the argument name just to silence the compiler?
I can only see that happening for functions in interface classes that defines some kind of callback, and that for some reason need to have a (more or less) dummy body (the warning should of course be disabled for pure declarations).
In such cases I'd be fairly satisfied with the option of providing a more complete function declaration using @decl in a refdoc comment.
If worst comes to worst, it's always possible to give a name in a comment instead:
string chop_chop (object /*context*/, string data) {return data;}
I think we've had this discussion a while ago an decided agains nameless parameters.
I'd rather have unused arguments become an optional warning in the compiler than any other wierd workaround. That way, I can detect them if I want to but for the most part just ignore them.
We had a discussion that ended up in a descision to remove warnings for unused variable and add a #pragma for turning it on. I don't remember anything about nameless parameters.
An all-on/all-off switch doesn't sound particularly useful. It's for each individual argument one wants to make the decision whether it's intended to remain unused or not.
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
An all-on/all-off switch doesn't sound particularly useful. It's for each individual argument one wants to make the decision whether it's intended to remain unused or not.
What about something similar to __attribute__(unused) like gcc has?
E.g. int somefunc(int __attribute__(unused) level, int depth) { }
in order to suppress warnings for "int level".
Only problem is that something like that would be exceedingly clumsy. It would force everyone to invent his own little macro (since pike by convention doesn't have a common include file system), which would obscure the meaning.
When is there a point of warning of unused arguments to a function?
Have an
__attribute__(warn_if_unused)
instead? ;)
For most functions the warning makes sense in strict mode. That's when you should have a clean, finished function with the cruft removed.
The exceptions become painful though: callbacks and #ifdefs. And sometimes when you develop in strict mode, because you will have unused arguments while fiddling with things.
Plus deprecated arguments in APIs, but the compiler already have the deprecate flag to hang that on.
But it's extraordinarily painful when you write things using callback API:s.
So, basically, I should put a __attribute__(unused) at about every other function defenition in my asynchronous storage system, or skip strict types?
No you shouldn't because that would suck. that's why it should be turned on with a separate #pragma for now. I'm just saying that if possible to make non-irritating the warning is nice in most cases.
I'm not sure if I see arguments, even unused, as cruft. They are usually both for method compatibility and/or documentation when they aren't used, and that's not usually something that you want to remove just because it's a "finished product".
pike-devel@lists.lysator.liu.se
-
Marcus Agehall (Roxen IS) ＠ Pike (-) developers forum -
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum
-
Stephen R. van den Berg