Jump to page: 1 2
Thread overview
Docs: Section on local variables
Apr 20, 2012
Andrej Mitrovic
Apr 20, 2012
Jakob Ovrum
Apr 20, 2012
Nick Sabalausky
Apr 20, 2012
Jakob Ovrum
Apr 20, 2012
Timon Gehr
Re: Section on local variables
Apr 20, 2012
Nick Sabalausky
Apr 20, 2012
Andrej Mitrovic
Apr 20, 2012
Nick Sabalausky
Apr 20, 2012
H. S. Teoh
Apr 20, 2012
bearophile
Apr 20, 2012
Timon Gehr
Apr 20, 2012
bearophile
Apr 20, 2012
Timon Gehr
Apr 20, 2012
Nick Sabalausky
Apr 20, 2012
bearophile
Apr 20, 2012
Nick Sabalausky
April 20, 2012
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
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
"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
"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
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
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
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
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
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
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