On Wed, 01 Aug 2012 11:38:46 +0100, bearophile <bearophileHUGS@lycos.com> wrote:

> Regan Heath:
>
>> Indeed.  IIRC Walter's rationale on things like this has always been that they belong in 3rd party tools.
>
> Walter is not always right.

Well, in this case I agree with him.  You're not looking at the big picture.  If you make detecting un-used variables a /requirement/ for implementing a D compiler, you make it that much less likely someone will write one, which raises the bar for D's adoption.  The reason why there are so few good C++ compilers is that the language is too hard to implement, we don't want D to go that way.

>> It's why the DMD front end is available for use, so people can create tools like this, syntax highlighters, re-formatters, dependency tree diagrams, or... you name it.
>
> Detecting unused variables is a core feature, it belongs in the compiler

Says you.  I disagree.  We may have gotten used to it being there, but it's not part of the "compilation" phase but rather part of the "development" phase and/or the "quality control" phase which are arguably the realm of the IDE or a "lint" checker.

> like compile-time array bound tests and other errors currently detected by DMD.

The key word used here is "error". Unused variables do not affect the compilation of a program, they're simply ignored and have no effect.  Array bounds errors will crash the program.

> This allows everyone to use it with minimum work, so everyone enjoys it, and it requires less work to be implemented because the compiler already does lot of analysis.

Sure, but everyone is not the bottleneck, Walter is.  The work to implement it has to be done by someone, somewhere.  If we make it a requirement for a D compiler then every D compiler writer has to do it, including Walter and as a result all D compilers will be that much worse for the wasted time/energy used to implement it, not to mention fix any bugs that arise - as they will be very visible - despite being almost irrelevant to the main purpose of the "compiler".

If it's done by a 3rd party tool it will be done better - as more time can be spent on it, as it's a main feature of said tool, etc.

In short, it's better for everyone if it's done in a 3rd party tool.  Further, that tool could be fully integrated, i.e. distributed by/with the compiler and run as a pre or post compile step automatically such that to users it's indistinguishable whether the compiler or the tool is doing the work.

All we need is someone to produce and maintain the tool, and for Walter to add it to the distribution and hook it into the compiler.  Then, we can have competing tools, and competition breeds improvement..

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

The Go compiler is able to detect unused variables, and strangely they are regarded as an error.

On 8/1/2012 5:38 PM, bearophile wrote:
> Detecting unused variables is a core feature, it belongs in the
> compiler, like compile-time array bound tests and other errors currently
> detected by DMD. This allows everyone to use it with minimum work, so
> everyone enjoys it, and it requires less work to be implemented because
> the compiler already does lot of analysis.
>
> Bye,
> bearophile

On Wed, 01 Aug 2012 12:03:01 +0100, Andre Tampubolon <andre@lc.vlsm.org> wrote:

> The Go compiler is able to detect unused variables, and strangely they are regarded as an error.

It's not really a question of "able" to, or not.  I'm sure were Walter to decide to add this feature to D he would also be "able" to.

It also doesn't matter what another language choses to do.

Why you'd want an unused variable to be an error is beyond me - it has absolutely no effect on the resulting executable, if it did it would be a bug.

What matters, ultimately, from a user point of view is whether the feature exists or not.  We can solve that by having a 3rd party tool bundled with the compiler and this would be the best solution for all the reasons outlined earlier.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Regan Heath:

> If you make detecting un-used variables a /requirement/ for implementing a D compiler, you make it that much less likely someone will write one,

Detecting unused variables can be written as a part of the front-end. It's meant to be shared by LDC and GDC that use the same front-end.


>We may have gotten used to it being there, but it's not part of the "compilation" phase but rather part of the "development" phase and/or the "quality control" phase which are arguably the realm of the IDE or a "lint" checker.<

In theory you are right, in practice I don't know how much this idea is applicable to D/DMD and how much good it does.
In Clang they have added a switch to perform extra static tests on the code. It's a feature built in the compiler. I think this is an acceptable place to put an unused variable warning in DMD.
They have also built a stand alone analyzer, as you say:
http://clang-analyzer.llvm.org/
But this isn't a fully isolated tool, it re-uses large parts of the compiler, it's like a plug-in. I think you can't do this with DMD (maybe it can be done with LDC, but we were talking about a portable tool for D).


> It also doesn't matter what another language choses to do.

I think that detecting unused variables is part of all C# compilers too. Looking at other languages is useful because the C# designers are very smart, and C# share most needs with D. C# doesn't have C++/D-style templates, this may add some unused variables to D code, but the situation is not too much different.


>Why you'd want an unused variable to be an error is beyond me - it has absolutely no effect on the resulting executable, if it did it would be a bug.<

For a D detector of unused variables I was asking for a warning, as in C#.

And regarding Go, I can't read the mind of the Go designers, but I think they don't like warnings, on the other hand they want a very tidy Go code, so they have made it an error. Go doesn't have templates and it seems so far its programmers are surviving to the presence of this error.

They want tidy code because experience shows that often variables that are defined and not used are spots where the programmer has forgotten something, and sometimes some code is missing.

Beside unused variables warning, I'd like another warning, unused last assignment warning, it helps find other bugs:
http://d.puremagic.com/issues/show_bug.cgi?id=4694

Thank you,
bye,
bearophile

On 08/01/2012 12:38 PM, bearophile wrote:
> Regan Heath:
>
>> Indeed. IIRC Walter's rationale on things like this has always been
>> that they belong in 3rd party tools.
>
> Walter is not always right.
>
>
>> It's why the DMD front end is available for use, so people can create
>> tools like this, syntax highlighters, re-formatters, dependency tree
>> diagrams, or... you name it.
>
> Detecting unused variables is a core feature,

No. This mustn't be part of the language.

http://d.puremagic.com/issues/show_bug.cgi?id=7989

> it belongs in the
> compiler, like compile-time array bound tests and other errors currently
> detected by DMD. This allows everyone to use it with minimum work, so
> everyone enjoys it, and it requires less work to be implemented because
> the compiler already does lot of analysis.
>

It is not an error. Making things that are not errors illegal is prone
to introduce bugs into code using __traits(compiles).

This can be a warning at best.

On Wed, 01 Aug 2012 15:52:22 +0100, bearophile <bearophileHUGS@lycos.com> wrote:
> Regan Heath:
>
>> If you make detecting un-used variables a /requirement/ for implementing a D compiler, you make it that much less likely someone will write one,
>
> Detecting unused variables can be written as a part of the front-end.

Or it can be written using the front-end.

> It's meant to be shared by LDC and GDC that use the same front-end.

Why?

>> We may have gotten used to it being there, but it's not part of the "compilation" phase but rather part of the "development" phase and/or the "quality control" phase which are arguably the realm of the IDE or a "lint" checker.<
>
> In theory you are right, in practice I don't know how much this idea is applicable to D/DMD and how much good it does.
> In Clang they have added a switch to perform extra static tests on the code. It's a feature built in the compiler. I think this is an acceptable place to put an unused variable warning in DMD.

You're missing my main point which is that you can get the appearance of a compiler feature with a 3rd party tool bundled with the compiler, the difference/benefits of a 3rd party tool are:

1. The "feature" it implements is not a requirement for all D compilers.
2. Walter doesn't have to implement it.

And more minor points include:

3. We can have competition between 3rd party vendors.
4. People can select/run their favorite tool.
5. A crashing tool/feature will no stop compilation.

Basically, having a 3rd party tool will look exactly like a feature of the compiler, but it will be better for the reasons above.

R

On Wednesday, August 01, 2012 17:07:31 Timon Gehr wrote:
> On 08/01/2012 12:38 PM, bearophile wrote:
> > Regan Heath:
> >> Indeed. IIRC Walter's rationale on things like this has always been that they belong in 3rd party tools.
> > 
> > Walter is not always right.
> > 
> >> It's why the DMD front end is available for use, so people can create tools like this, syntax highlighters, re-formatters, dependency tree diagrams, or... you name it.
> > 
> > Detecting unused variables is a core feature,
> 
> No. This mustn't be part of the language.
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=7989
> 
> > it belongs in the
> > compiler, like compile-time array bound tests and other errors currently
> > detected by DMD. This allows everyone to use it with minimum work, so
> > everyone enjoys it, and it requires less work to be implemented because
> > the compiler already does lot of analysis.
> 
> It is not an error. Making things that are not errors illegal is prone to introduce bugs into code using __traits(compiles).
> 
> This can be a warning at best.

And you can't have anything be a warning if it's not something that should always be fixed, because it's never good practice to leave warnings in your code (especially since if you do, it becomes difficult to see the ones that actually  matter). The fact that D has -w makes it that much critical that a warning be _guaranteed_ to be something that should be fixed.

And unused variables have too many valid use cases in D: template constraints, generic code, RAII, etc. You can't make them either an error, and if you can't make them an error, you can't make them a warning. The only real difference between an error and a warning as far as dmd goes is if it's something that must _always_ be fixed before your code can compile. It's not something that should be left in your source code in either case, and given how many people compile with -w, there's often effectively zero difference between warnings and errors when using dmd.

- Jonathan M Davis

Timon Gehr:

> No. This mustn't be part of the language.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=7989

I agree there are some problems. But not putting this warning in the default language means such problems will not be faced at the language level itself too. So maybe no good solutions will be found to those problems. So maybe it needs to be an integrated & well designed feature of D.


> This can be a warning at best.

The enhancement request is for a warning :-)

Bye,
bearophile