Warn on unused imports?

Nick Sabalausky (Abscissa) SeeWebsiteToContactMe at semitwist.com
Tue Oct 2 02:03:39 UTC 2018


On 10/01/2018 04:58 PM, Jonathan M Davis wrote:
> On Monday, October 1, 2018 2:44:32 PM MDT Nick Sabalausky (Abscissa) via
> Digitalmars-d wrote:
>>
>> Nobody said anything about making them part of the build process. We're
>> talking about them being included in the compiler, not about them being
>> in the build process. Please don't move the goalposts.
> 
> dmd -w
> 
> and
> 
> dmd -wi
> 
> build your program. Printing warnings is part of the build process.

dmd

or

dmd -w -o-

Just like external tools, they're NOT part of the build process unless 
you CHOOSE to make them part of your build process. (Though, with 
external tools, there's an unavoidable added performance penalty. But if 
you don't want them part of the build then I guess that penalty becomes 
moot.)

>> That is purely playing around with word semantics. Deprecations in DMD
>> are a non-fatal message about something that might need fixed sooner or
>> later. That is what a warning is. Implementation details do nothing to
>> change that.
> 
> Deprecations are fundamentally different from compiler warnings. In the case
> of a deprecation, your code _will_ break if you don't change it once the
> deprecation period ends, whereas a compiler warning is just telling you
> about something that the compiler thinks might be wrong wiith your code.

If not fixing it *will* cause breakage then, by your stance, shouldn't 
it be an error (or silence)? I thought you were against the build 
process pointing out issues with your code without making them outright 
errors?

If you're opposed to a warnings' non-error status because the warning 
*might* indicate a problem, then *certainly* you'd also be opposed to 
non-error status for something that *will* be a problem, right? Do you 
*really* consider "maybe a problem" more serious than "definitely a 
problem"?

But you're splitting hairs anyway. Either way, you have things that 
likely[1] should be improved (or at least looked into), but don't 
immediately require action. Fundamentally, same effing thing.

[1] Yes, the strength of this "likely" varies from warning to warning. 
But it does so even aside from deprecations.


More information about the Digitalmars-d mailing list