On Monday, 30 July 2012 at 21:13:42 UTC, Andrej Mitrovic wrote:
> On 7/30/12, Namespace <rswhite4@googlemail.com> wrote:
>> BTW: Has anyone test my detector and could give me some
>> suggestions or critism?
>>
>
> I've tried it out and it didn't find any unused variables, but I doubt
> this is true, I'm not very tidy when it comes to using variables. I do
> use a lot of templates so maybe the script bailed on those.

Templates and object types aren't supported right now. But maybe next time.
Until now only primitive types are being detected. But if you have code where you think my programm fails, then i'm very glad if you will post it here. :)

Jonathan M Davis:

> This is the sort of thing that's
> better left to a lint-like tool IMHO.

Putting it in a lint means people have to know what a lint is, desire to search it, install, and add its running to their compilation ways. It also means the lint needs to contain part of a D compiler. Most people I know don't use lints for their C/C++ code. On the other the C# programmers see such errors on default, with no lint. So this idea is good if the lint is built in the compiler, as the analysis option of Clang, do you know about it?

Bye,
bearophile

On 31-Jul-12 01:37, bearophile wrote:
> Jonathan M Davis:
>
>> This is the sort of thing that's
>> better left to a lint-like tool IMHO.
>
> Putting it in a lint means people have to know what a lint is, desire to
> search it, install, and add its running to their compilation ways.

Just run it once on each release candidate. People constantly seek tools to improve quality of their release code and catch possible bugs that should be enough of motivation to install lint.

>It
> also means the lint needs to contain part of a D compiler.
Yeah when was the last time we had this compile as library "discussion"?

> Most people I
> know don't use lints for their C/C++ code.

Most people I know ignore warnings. "Most people I know" is hardly good enough argument. e.g. "most people I know hate tons of compiler switches"

> On the other the C#
> programmers see such errors on default, with no lint. So this idea is
> good if the lint is built in the compiler, as the analysis option of
> Clang, do you know about it?
>

I know but DMD won't have it in near future. Other compilers may do what they want to do.


-- 
Dmitry Olshansky

Dmitry Olshansky:

> "Most people I know" is hardly good enough argument.

The point is that this warning is a basic thing, other compilers have it and I enjoy it in those languages and putting this feature into external tools is not going to help most D programmers.


> I know but DMD won't have it in near future.

There is a long list of things Walter has done to D/DMD in the last four years that initially seemed contrary to his opinions and nearly impossible to happen :-) Bugzilla shows that most of my most important enhancement requests have being accepted. Walter is not set in stone, he's sometimes very slow, but he never stops moving forward, unlike lot of other people I know.


>Other compilers may do what they want to do.<

Right. If LDC/GDC introduce this warning and we are able to show its usefulness, maybe Walter will change his mind.
In the last two years Walter has introduced in DMD many bugfixes and changes suggested by static analyzers/lints, including Clang, and he has removed several unused variables from DMD suggested by those tools :-]

Bye,
bearophile

On 31-Jul-12 02:02, bearophile wrote:
> Dmitry Olshansky:
>
>> "Most people I know" is hardly good enough argument.
>
> The point is that this warning is a basic thing, other compilers have it
> and I enjoy it in those languages and putting this feature into external
> tools is not going to help

I'm seeing the same argument over and over again :)

 most D programmers.



-- 
Dmitry Olshansky

Dmitry Olshansky:

> I'm seeing the same argument over and over again :)
>
>  most D programmers.

What do you look for? A language designed for 5-10% of its users? No thanks.

Bye,
bearophile

I agree that having the compiler make warnings about unused
variables is a really good idea!!!

Java has it and when I program in eclipse it's really useful
because the editor can highlight the particular lines.

On 07/31/2012 11:55 AM, Minas wrote:
> I agree that having the compiler make warnings about unused
> variables is a really good idea!!!
>
> Java has it and when I program in eclipse it's really useful
> because the editor can highlight the particular lines.

An editor can be configured to point it out even if it is not in the
language, if it is considered useful.

On Mon, 30 Jul 2012 18:41:51 +0100, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Monday, July 30, 2012 18:50:08 Andrej Mitrovic wrote:
>> On 7/30/12, Namespace <rswhite4@googlemail.com> wrote:
>> > IMO something like this should be integrated into the D compiler.
>>
>> As long as it's togglable via a compiler switch. :)
>
> Walter doesn't like compiler switches like that, and he doesn't like it when
> the compiler complains about unused variables. So, I wouldn't expect it to
> happen, but anyone's free to create a pull request and try.

Indeed.  IIRC Walter's rationale on things like this has always been that they belong in 3rd party tools.  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.

R

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

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, 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