View mode: basic / threaded / horizontal-split · Log in · Help
April 20, 2012
Docs: Section on local variables
Can we remove this section from the D docs, in the functions section? :

"
Local Variables
It is an error to use a local variable without first assigning it a
value. The implementation may not always be able to detect these
cases. Other language compilers sometimes issue a warning for this,
but since it is always a bug, it should be an error.

It is an error to declare a local variable that is never referred to.
Dead variables, like anachronistic dead code, are just a source of
confusion for maintenance programmers.
"

I don't think this will ever be implemented, or that it should be for
that matter. The first paragraph is quite extreme. As for the second
one, think about how often you use temporary variables just to test
something out, you wouldn't want to have a compilation error just
because you've temporarily left an unused variable inside a function.
That's my experience anywho..

I think these features probably belong to some lint-type tool and not
the compiler.
April 20, 2012
Re: Docs: Section on local variables
On Friday, 20 April 2012 at 01:22:53 UTC, Andrej Mitrovic wrote:
> Can we remove this section from the D docs, in the functions 
> section? :
>
> "
> Local Variables
> It is an error to use a local variable without first assigning 
> it a
> value. The implementation may not always be able to detect these
> cases. Other language compilers sometimes issue a warning for 
> this,
> but since it is always a bug, it should be an error.
>
> It is an error to declare a local variable that is never 
> referred to.
> Dead variables, like anachronistic dead code, are just a source 
> of
> confusion for maintenance programmers.
> "
>
> I don't think this will ever be implemented, or that it should 
> be for
> that matter. The first paragraph is quite extreme.

Many other languages have this restriction on local variables and
I would love to see DMD do the same kind of analysis. You can't
force programmers to write readable code, but you should at least
discourage it; the current way of default-initializing local
variables and using that as an excuse to not have flow analysis
is extremely weak and just reflects an unwillingness of the DMD
developers to take on this task, affecting the design of the
language.

I have seen this one in the wild before:

for(size_t i; i < arr.length; i++) {
     ...
}

This shouldn't be correct D code, and I think it's one of D's few
weaknesses that it is. Removing this paragraph from the
specification would be designing the language around DMD instead
of the other way around, and I really don't want to see that.

> As for the second one, think about how often you use temporary 
> variables just to test
> something out, you wouldn't want to have a compilation error 
> just
> because you've temporarily left an unused variable inside a 
> function.
> That's my experience anywho..

I think GDC has warnings for this, and I think that's the way to
go. Unused local variables is a plague on readability and we
should strive to eliminate them; but at the same time, a
compilation error for all circumstances may be a little tedious.

> I think these features probably belong to some lint-type tool 
> and not
> the compiler.

If I remember correctly, one of the goals of D according to
Walter is to reduce the need for such external tools.
April 20, 2012
Re: Section on local variables
"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message 
news:mailman.1946.1334885029.4860.digitalmars-d@puremagic.com...
> Can we remove this section from the D docs, in the functions section? :
>
> "
> Local Variables
> It is an error to use a local variable without first assigning it a
> value. The implementation may not always be able to detect these
> cases. Other language compilers sometimes issue a warning for this,
> but since it is always a bug, it should be an error.
>

Wow, as much as I like it, that's very non-D-like. C# has it which I always 
liked. But from discussions, Walter seemed very much against it. So I'm very 
surprised that's even there.

> It is an error to declare a local variable that is never referred to.
> Dead variables, like anachronistic dead code, are just a source of
> confusion for maintenance programmers.
> "
>

We don't even have a warning for that. (I've asked for one ages ago, but I 
don't think it's gonna happen: 
http://d.puremagic.com/issues/show_bug.cgi?id=2197  - I don't know what the 
hell I was thinking with that over-contrived example though) I wouldn't want 
it to be an error, because like you said, that'd be a PITA for temporary 
code paths, but I always felt it would be helpful as a warning. But, 
uhh...someone...hates warnings though... ;)
April 20, 2012
Re: Docs: Section on local variables
"Jakob Ovrum" <jakobovrum@gmail.com> wrote in message 
news:lehdgtfkqawadxgsgymv@forum.dlang.org...
> On Friday, 20 April 2012 at 01:22:53 UTC, Andrej Mitrovic wrote:
>> Can we remove this section from the D docs, in the functions section? :
>>
>> "
>> Local Variables
>> It is an error to use a local variable without first assigning it a
>> value. The implementation may not always be able to detect these
>> cases. Other language compilers sometimes issue a warning for this,
>> but since it is always a bug, it should be an error.
>>
>> It is an error to declare a local variable that is never referred to.
>> Dead variables, like anachronistic dead code, are just a source of
>> confusion for maintenance programmers.
>> "
>>
>> I don't think this will ever be implemented, or that it should be for
>> that matter. The first paragraph is quite extreme.
>
> Many other languages have this restriction on local variables and
> I would love to see DMD do the same kind of analysis. You can't
> force programmers to write readable code, but you should at least
> discourage it; the current way of default-initializing local
> variables and using that as an excuse to not have flow analysis
> is extremely weak and just reflects an unwillingness of the DMD
> developers to take on this task, affecting the design of the
> language.
>
> I have seen this one in the wild before:
>
> for(size_t i; i < arr.length; i++) {
>      ...
> }
>
> This shouldn't be correct D code, and I think it's one of D's few
> weaknesses that it is. Removing this paragraph from the
> specification would be designing the language around DMD instead
> of the other way around, and I really don't want to see that.
>

It's funny, I once argued strongly in favor of this *against* Walter. I lost 
of course ;) IIRC, his argument was that it would require perfect flow 
analysis and that's too difficult and expensive. My argument was that it 
didn't need to be, and perhaps even *shouldn't* be, perfect. He felt that 
would end up being a PITA with false errors, and I felt that C# demonstrates 
it isn't a PITA.  Meh, I don't want to re-debate it though.

>> I think these features probably belong to some lint-type tool and not
>> the compiler.
>
> If I remember correctly, one of the goals of D according to
> Walter is to reduce the need for such external tools.

I've argued in the past that warnings *are* a lint tool. The powers that be 
didn't seem to agree though.
April 20, 2012
Re: Docs: Section on local variables
On Friday, 20 April 2012 at 09:55:04 UTC, Nick Sabalausky wrote:

> It's funny, I once argued strongly in favor of this *against* 
> Walter. I lost
> of course ;) IIRC, his argument was that it would require 
> perfect flow
> analysis and that's too difficult and expensive. My argument 
> was that it
> didn't need to be, and perhaps even *shouldn't* be, perfect. He 
> felt that
> would end up being a PITA with false errors, and I felt that C# 
> demonstrates
> it isn't a PITA.  Meh, I don't want to re-debate it though.

Yeah, I am aware of Walter's previous statements on this. I think 
it's ridiculous that he wants his language inferior to virtually 
every one of its modern contemporaries in this aspect based on 
implementation issues. I like D's well-defined 
default-initialization and I think it's great for global storage, 
TLS and class/struct fields, but I think local variables require 
a hybrid approach. It doesn't matter if the implementation isn't 
perfect; it's better than the alternative, which is our current 
abysmal situation.
April 20, 2012
Re: Docs: Section on local variables
Andrej Mitrovic:

> I think these features probably belong to some lint-type tool 
> and not the compiler.

On the contrary, I hope to see them implemented in the D 
front-end. I've seen again and again that people don't even use 
warnings, so I don't think many of them use lints. This means, 
tests should be built-in and active on default (this means I'd 
like D informational warnings to be active on default, and be 
disabled with a compiler switch!).

Bye,
bearophile
April 20, 2012
Re: Docs: Section on local variables
On 04/20/2012 12:07 PM, Jakob Ovrum wrote:
> On Friday, 20 April 2012 at 09:55:04 UTC, Nick Sabalausky wrote:
>
>> It's funny, I once argued strongly in favor of this *against* Walter.
>> I lost
>> of course ;) IIRC, his argument was that it would require perfect flow
>> analysis and that's too difficult and expensive.
> My argument was that it
>> didn't need to be, and perhaps even *shouldn't* be, perfect. He felt that
>> would end up being a PITA with false errors, and I felt that C#
>> demonstrates
>> it isn't a PITA. Meh, I don't want to re-debate it though.
>
> Yeah, I am aware of Walter's previous statements on this. I think it's
> ridiculous that he wants his language inferior to virtually every one of
> its modern contemporaries in this aspect based on implementation issues.

Why do you think it is an implementation issue? D already requires an 
implementation to have flow-analysis.

> I like D's well-defined default-initialization and I think it's great
> for global storage, TLS and class/struct fields, but I think local
> variables require a hybrid approach. It doesn't matter if the
> implementation isn't perfect;

It certainly does. Compiler errors for non-issues hamper productivity 
and are good for nothing.

> it's better than the alternative, which is
> our current abysmal situation.
>

'abysmal'? Seriously? This could go either way, and personally, I like 
the current way better.

Maybe the implementation could be non-conservative: The warning would 
pop up only if it can be proven by flow-analysis that a local variable 
is accessed without preceding explicit initialisation. Anyway, why would 
this be such a huge deal?
April 20, 2012
Re: Docs: Section on local variables
On 04/20/2012 01:04 PM, bearophile wrote:
> Andrej Mitrovic:
>
>> I think these features probably belong to some lint-type tool and not
>> the compiler.
>
> On the contrary, I hope to see them implemented in the D front-end.
> I've seen again and again that people don't even use warnings, so I don't
> think many of them use lints.
> This means, tests should be built-in and
> active on default (this means I'd like D informational warnings to be
> active on default, and be disabled with a compiler switch!).
>

I don't usually use warnings because of this issue:
http://d.puremagic.com/issues/show_bug.cgi?id=6552
April 20, 2012
Re: Docs: Section on local variables
Timon Gehr:

> I don't usually use warnings because of this issue:
> http://d.puremagic.com/issues/show_bug.cgi?id=6552

Unspecified falltrough is going to become an error, so it's not a 
good example of warning.

And if you are trying to say that warnings are not so good 
because they sometimes warn against something actually correct, 
that's a DMD bug, so again it's not a good example :-)

Regarding the OP topic I have opened:
http://d.puremagic.com/issues/show_bug.cgi?id=3960
http://d.puremagic.com/issues/show_bug.cgi?id=4694

Bye,
bearophile
April 20, 2012
Re: Docs: Section on local variables
On 04/20/2012 03:36 PM, bearophile wrote:
> Timon Gehr:
>
>> I don't usually use warnings because of this issue:
>> http://d.puremagic.com/issues/show_bug.cgi?id=6552
>
> Unspecified falltrough is going to become an error,

Hopefully after the bug is fixed.

> so it's not a good example of warning.
>

It is a warning now. One example is sufficient.

> And if you are trying to say that warnings are not so good

I am not saying that warnings are not so good. I am saying I don't 
(even) _use_ them currently.

> because they sometimes warn against something actually correct,

I'd claim, most of the time.

> that's a DMD bug,

Not necessarily. Often, warnings have to be conservative. Especially in 
the case discussed in the OP.

> so again it's not a good example :-)

I am not sure what you are trying to say.

>
> Regarding the OP topic I have opened:
> http://d.puremagic.com/issues/show_bug.cgi?id=3960
> http://d.puremagic.com/issues/show_bug.cgi?id=4694
>
> Bye,
> bearophile
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home