Bug 20167 – Issue warning when result discarded from strong pure function?
Status
RESOLVED
Resolution
WORKSFORME
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2019-08-25T23:31:07Z
Last change time
2023-04-18T11:12:29Z
Assigned to
No Owner
Creator
Manu
Comments
Comment #0 by turkeyman — 2019-08-25T23:31:07Z
It would be nice to have a compile error (or warning maybe) when the user discards the result from a stong pure function.
If the function receives args `const`, and has no side effects, then calling the function is completely redundant if the result is discarded.
At best it's pointless and inefficient, but in practise it's almost certainly a bug that the user didn't notice.
Comment #1 by dkorpel — 2019-08-26T00:43:56Z
(In reply to Manu from comment #0)
> It would be nice to have a compile error (or warning maybe) when the user
> discards the result from a stong pure function.
```
int f() nothrow pure {
return 1;
}
void main() {
f();
}
```
When compiling with -w:
onlineapp.d(6): Warning: calling onlineapp.f without side effects discards return value of type int, prepend a cast(void) if intentional
Is there anything lacking on the current warning or can this be closed?
Comment #2 by turkeyman — 2019-08-26T00:54:27Z
Interesting.
I did this same test, but I didn't have `nothrow`.
Why wasn't `nothrow` inferred for this trivial function where the source is as plain as day to the compiler?
We're meant to be all about attribute inference these days.
Comment #3 by iamthewilsonator — 2021-03-21T13:31:39Z
> Why wasn't `nothrow` inferred for this trivial function where the source is as plain as day to the compiler?
FWIW the compiler does inference if the function is a template or the return type is auto: that is
auto f() {
return 1;
}
and
int f()() {
return 1;
}
will trigger a warning when compiled with -w
Comment #4 by razvan.nitu1305 — 2023-04-18T11:12:29Z
> I did this same test, but I didn't have `nothrow`.
Why wasn't `nothrow` inferred for this trivial function where the source is as plain as day to the compiler?
We have been discussing about this for a long time, but I don't know if attribute inference is going to be a thing for normal functions. That could be filed as a different issue.
However, this bug report, as Dennis pointed out has nothing actionable.