On 25/04/2012 12:30, Stewart Gordon wrote:
> On 21/04/2012 17:26, Andrej Mitrovic wrote:
> <snip>
>> Next thing you know the compiler will start warning me when I indent
>> my code with uneven number of spaces!
>
> Or more usefully, warn if you have a mishmash of tab and space indentation.
>
> How do indent-sensitive languages (Haskell, Python, whatever else) deal with mixed
> tab/space indentation, for that matter?

Just found out
http://urchin.earth.li/~ian/style/haskell.html
http://www.secnetix.de/olli/Python/block_indentation.hawk
that both Haskell and Python uses a tab size of 8 characters.  Personally, I think they should error if the meaning of a section of code depends on the tab size.

OTOH, YAML avoids the issue in the strictest way possible: forbidding tab characters.  I wonder if there are other languages that require you to indent with tabs.

But one possible design for languages like these is to allow indentation to be either entirely spaces or entirely tabs, but not a mixture.  This would also be a good way for linters for a variety of languages to behave.

Another way would be to allow tabs, spaces or a mixture, with the only restriction being that a given block must be consistently indented with the same sequence of tabs/spaces.

Stewart.

On 04/25/2012 06:10 PM, Andrej Mitrovic wrote:
> On 4/25/12, Stewart Gordon<smjg_1998@yahoo.com>  wrote:
>> Even if it's left over from debugging, it
>> looks silly, and
>> might lead other people reading the code to believe something's wrong.
>
> There's about a million ways to make code unreadable, and nobody
> writes pitch-perfect code that has absolutely no leftover code or
> comments.
>
> And what if you're refactoring and you do multiple builds every couple
> of seconds? You add a variable, remove it, etc etc. Enabling this
> warning will just make for a noisy compiler. Keeping variables clean
> is the responsibility of the programmer and not the compiler.
>
> If it doesn't affect the semantics of code the compiler should shut
> up. Please don't turn the compiler into a reincarnation of Clippy.

+1.

Another thing: It might not be unused in every static code path.

Even more important:

template isInputRange(R)
{
    enum bool isInputRange = is(typeof(
    {
        R r;              // can define a range object
        if (r.empty) {}   // can test for empty
        r.popFront();     // can invoke popFront()
        auto h = r.front; // can declare an unused variable
    }()));
}

Having these kinds of errors in the compiler would be a major PITA that
butchers the language without any benefit for correct code. This should
not be the responsibility of the compiler. It is not a good match for D.

On 26/04/2012 08:26, Timon Gehr wrote:
<snip>
> Another thing: It might not be unused in every static code path.

One way to deal with this would be to do the checking before conditional compilation. That said, I've a feeling that mixin expansion might get in the way of this.

> Even more important:
>
> template isInputRange(R)
> {
> enum bool isInputRange = is(typeof(
> {
> R r; // can define a range object
> if (r.empty) {} // can test for empty
> r.popFront(); // can invoke popFront()
> auto h = r.front; // can declare an unused variable
<snip>

cast(void) r.front;

Stewart.

Stewart Gordon:

> But one possible design for languages like these is to allow indentation to be either entirely spaces or entirely tabs, but not a mixture.  This would also be a good way for linters for a variety of languages to behave.

Among the arguments of the Python2.6 interpreter there is also:

-t     : issue warnings about inconsistent tab usage (-tt: issue errors)

"inconsistent tab usage" means mixing tabs and spaces.

Bye,
bearophile

Timon Gehr:

> Andrej Mitrovic:
>> Keeping variables clean
>> is the responsibility of the programmer and not the compiler.
>>
>> If it doesn't affect the semantics of code the compiler should shut up. Please don't turn the compiler into a reincarnation of Clippy.
>
> +1.

I think currently the D compiler doesn't shut up in some cases.

Comparing the unused variable warning with Clippy is not good. Clippy gives suggestions, while here the compiler is giving something more like an error message.


> Another thing: It might not be unused in every static code path.
>
> Even more important:
>
> template isInputRange(R)
> {
>     enum bool isInputRange = is(typeof(
>     {
>         R r;              // can define a range object
>         if (r.empty) {}   // can test for empty
>         r.popFront();     // can invoke popFront()
>         auto h = r.front; // can declare an unused variable
>     }()));
> }

If the unused variable is a warning, and I use "-wi" that code compiles.

The warning for unused variables helps me clean up my C code and has avoided me more than one bug. So I'd like this optional warning in the D front-end. I'd even like a warning for variables assigned and then later never read again.

Bye,
bearophile

On 26/04/2012 08:26, Timon Gehr wrote:
<snip>
> template isInputRange(R)
> {
> enum bool isInputRange = is(typeof(
> {
> R r; // can define a range object
> if (r.empty) {} // can test for empty
> r.popFront(); // can invoke popFront()
> auto h = r.front; // can declare an unused variable
> }()));
> }
<snip>

This is indeed a blocker for fixing it to work according to the current spec.  I've just filed
http://d.puremagic.com/issues/show_bug.cgi?id=7989
to address it.

Stewart.

On 26/04/2012 15:05, Stewart Gordon wrote:
<snip>
> http://d.puremagic.com/issues/show_bug.cgi?id=7989

From JMD:
"The fact that isInputRange and isForwardRange rely on
declaring variables which aren't used being legal. It would be really annoying
for unused local variables to be illegal when dealing with template constraint
stuff like isInputRange and isForwardRange. Code would have to be needlessly
contorted to deal with that fact, and you wouldn't ever get a good error about
why the result of the template was false, because it would be part of a
template constraint.

IHMO, the very issue that this bug report brings up highlights a good reason
why unused local variables should continue to be ignored by the compiler."

(on 3960)
"I think that issue# 7989 is a great argument for why there shouldn't be any
warnings or errors for unused variables. Such would needlessly make writing
template constraints harder."

Since this is relevant to both issues, I'll continue the discussion here.

I can begin to see why it makes errors for unused variables a bad idea.  But why no warnings?  Obviously the user wouldn't like to see warnings thrown at them when they try using templates with such constraints.  But:

- The average programmer is, the vast majority of the time, not writing template constraints, but trying to write bug-free application code.
- A quality compiler would swallow warnings generated by the content of IsExpressions, just as it already swallows errors generated by them - the only difference being that warnings don't cause the IsExpression to return false.

Stewart.

On Thu, 26 Apr 2012 14:46:38 -0400, Stewart Gordon <smjg_1998@yahoo.com> wrote:

> I can begin to see why it makes errors for unused variables a bad idea.  But why no warnings?  Obviously the user wouldn't like to see warnings thrown at them when they try using templates with such constraints.  But:
>
> - The average programmer is, the vast majority of the time, not writing template constraints, but trying to write bug-free application code.
> - A quality compiler would swallow warnings generated by the content of IsExpressions, just as it already swallows errors generated by them - the only difference being that warnings don't cause the IsExpression to return false.

I think the mechanism is highly desired, but gets in the way in a select few situations.  The best answer IMO is to disable that mechanism when it's not desired.  It's then an opt-out mechanism that doesn't require instrumenting most code.

Some ideas:

pragma(used) int x;
@used int x;

-Steve

On Thursday, April 26, 2012 19:46:38 Stewart Gordon wrote:
> I can begin to see why it makes errors for unused variables a bad idea. But why no warnings? Obviously the user wouldn't like to see warnings thrown at them when they try using templates with such constraints. But:

The existence of -w makes it so that warnings are just as bad as errors for something like this, since it makes warnings errors. The result is that there is a minimal difference between warnings and errors with dmd.

And honestly, while I agree that code shouldn't normally have unused variables, I so rarely see code with any that I think that it's a complete non-issue in general. I don't even know the last time that I saw an unused variable left in code (except for on purpose in something like isInputRange). I'd much prefer that warning about that sort of thing be left up to a lint-like tool.

- Jonathan M Davis

Jonathan M Davis:

> I don't even know the last time that I saw an unused
> variable left in code (except for on purpose in something like isInputRange).

So if the compiler warns you of unused variables, this will not cause your code almost no warnings. No troubles for you. For uncommon situations like isInputRange a specific annotation solves the problem cleanly.


> I'd much prefer that warning about that sort of thing be left up to a lint-like tool.

How many C/C++ programmers do you know that use lints? I think not enough. The Microsoft C++ compiler and Clang are adding more and more compile-time tests, replacing lints, this a trend D designers can't ignore. So saying "leave it to lints" it's almost like saying "ignore the problem".

Bye,
bearophile