Peter Alexander:

> This is a tricky one. On one hand, it *is* a useful way to catch errors, but on the other it's a constant source of irritation when you are tinkering with code during development/debugging.

I agree. I think a simple way to solve this problem is to put "unused variables" among the warnings. So when you are tinkering with code you don't use -wi, if you want.

-------------

eles:

> However, it is reasonable to include something like strictness
> levels as part of the compiler? (think gcc with MISRA-C
> integrated).

I think this to implement that there is a lot of work to do.

D tries to improve over C/C++ regarding static code safety, but there's a good way to go still (recently I have written a small article on this).

Bye,
bearophile

On 12/21/12, Walter Bright <newshound2@digitalmars.com> wrote:
> snip

Walter, can you verify if this is or isn't a bug:

.\main.d
.\foo.d

main.d:

module main;
import foo;
void main() { test(); }

foo.d:

module bar;
void test() { }

This is OK:

$ dmd -c main.d foo.d
> main.d(2): Error: module bar from file foo.d must be imported as
 module 'bar'

But this is questionable:
$ dmd -c main.d
> // no complaints

It seems the compiler doesn't complain about invalid import statements when it tries to find the module via its import path. Bug?

I remember having very weird issues with rdmd when module is called "main". May be this one is similar?

On Friday, 21 December 2012 at 14:52:27 UTC, Andrej Mitrovic wrote:
> On 12/21/12, Walter Bright <newshound2@digitalmars.com> wrote:
>> snip
>
> Walter, can you verify if this is or isn't a bug:
>
> .\main.d
> .\foo.d
>
> main.d:
>
> module main;
> import foo;
> void main() { test(); }
>
> foo.d:
>
> module bar;
> void test() { }
>
> This is OK:
>
> $ dmd -c main.d foo.d
>> main.d(2): Error: module bar from file foo.d must be imported as
>  module 'bar'
>
> But this is questionable:
> $ dmd -c main.d
>> // no complaints
>
> It seems the compiler doesn't complain about invalid import statements
> when it tries to find the module via its import path. Bug?

On Friday, December 21, 2012 14:19:32 Peter Alexander wrote:
> On Friday, 21 December 2012 at 08:58:03 UTC, bearophile wrote:
> > Walter Bright:
> >> another large source of irritation if unused imports are errors.
> > 
> > In Go even unused variables are *errors* :-)
> 
> This is a tricky one. On one hand, it *is* a useful way to catch errors, but on the other it's a constant source of irritation when you are tinkering with code during development/debugging.

It also doesn't work with stuff like RAII and a lot of conditional compilation. Particularly with eponymous templates, it's _very_ common to have unused variables. Warnings or errors for unused variables would be highly detrimental to D.

- Jonathan M Davis

Jonathan M Davis:

> It also doesn't work with stuff like RAII and a lot of conditional compilation.
> Particularly with eponymous templates, it's _very_ common to have unused
> variables. Warnings or errors for unused variables would be highly detrimental to D.

A warning for unused variables will also help D programmers avoid some bugs and keep their code tidy.

Bye,
bearophile

On Friday, December 21, 2012 18:46:20 bearophile wrote:
> Jonathan M Davis:
> > It also doesn't work with stuff like RAII and a lot of
> > conditional compilation.
> > Particularly with eponymous templates, it's _very_ common to
> > have unused
> > variables. Warnings or errors for unused variables would be
> > highly detrimental to D.
> 
> A warning for unused variables will also help D programmers avoid some bugs and keep their code tidy.

It doesn't work with the language - not with -w anyway. I know that you like the idea, but it just doesn't fly. Adding such a warning would literally change what code would and wouldn't compile and which branches of static ifs and whatnot were used. Some language features and idioms pretty much literally rely on the ability to have unused variables. As such, it's a horrible idea.

A lint-like tool is free to point them out for you, and maybe an IDE could highlight them, but actually making the compiler consider unused variables to be either a warning or an error would be an incredibly bad idea for D - on top of the fact that it would be really annoying.

- Jonathan M Davis

On 12/21/2012 06:59 PM, Jonathan M Davis wrote:
> A lint-like tool is free to point them out for you, and maybe an IDE could
> highlight them, but actually making the compiler consider unused variables to
> be either a warning or an error would be an incredibly bad idea for D - on top
> of the fact that it would be really annoying.

How about a separate compiler flag to warn about this issue alone?  Useful for those who want these checks, doesn't affect those who don't.

On Friday, December 21, 2012 20:29:43 Joseph Rushton Wakeling wrote:
> On 12/21/2012 06:59 PM, Jonathan M Davis wrote:
> > A lint-like tool is free to point them out for you, and maybe an IDE could highlight them, but actually making the compiler consider unused variables to be either a warning or an error would be an incredibly bad idea for D - on top of the fact that it would be really annoying.
> 
> How about a separate compiler flag to warn about this issue alone? Useful for those who want these checks, doesn't affect those who don't.

Not only are there perfectly legitimate uses for having used variables (e.g. RAII), but if used in combination with -w, such a flag would actually change the semantics of programs (due to have it affects conditional compilation), which is a major no-no. That and the fact that Walter has previously shown distaste both for warning about unused variables and for having lots of compiler flags, and I'd be very surprised if he added it. IDEs or or other tools are free to warn about it, but I think that it's a _very_ bad idea for the compiler itself to do so.

- Jonathan M Davis

On Friday, 21 December 2012 at 19:37:58 UTC, Jonathan M Davis wrote:
> Not only are there perfectly legitimate uses for having used variables (e.g.
> RAII) […]

Destructors with side effects could simply count as a "use" – problem solved.

> […] change
> the semantics of programs (due to have it affects conditional compilation),

Warnings should not affect conditional compilation, even if the user has warnings as errors turned on. The whole difference of warnings compared to errors is that they are not part of the language.

David

On Friday, December 21, 2012 20:58:02 David Nadlinger wrote:
> > […] change
> > the semantics of programs (due to have it affects conditional
> > compilation),
> 
> Warnings should not affect conditional compilation, even if the user has warnings as errors turned on. The whole difference of warnings compared to errors is that they are not part of the language.

The problem is -w, which plenty of people use. The effect is that any warning which can't be an error, can't be a warning. Warnings can therefore only be things that are definitively wrong but which are okay to let happen in some cases (as opposed to something which _might_ be wrong). If we didn't have -w, then we could use warnings for stuff which was probably but not definitively wrong and which was okay to force people to change (the fact that leaving in warnings is never good practice means that you can't warn for anything which it isn't reasonable to force people to change regardless of -w). But because of -w, you can't have any warnings where it would not be reasonable to treat them as an error. And it would be completely broken to treat warning about unused variables as an error.

- Jonathan M Davis