for loop - underscore placeholder

[Amitava]

I just started playing with Go. It looks cool.

For newb's like me, if you are using for with a range, like so

s = "the quick brown fox jumps right over the lazy dog";
for i,c := range(s) {
fmt.Println(c);
}

This will generate compiler error
amitava:go amitava$ make
6g hello.go
hello.go:36: i declared and not used
make: *** [hello.6] Error 1

Can't have unused variable. The fix is simple enough and I just hit
upon it intuitively - replace the unused variable 'i' with an
underscore like sp

s = "the quick brown fox jumps right over the lazy dog";
for _,c := range(s) {
fmt.Println(c);
}

-Amitava

[Robert Griesemer]

On Wed, Nov 11, 2009 at 1:28 PM, Amitava <amitav...@gmail.com> wrote:

I just started playing with Go. It looks cool.

thank you. 

For newb's like me, if you are using for with a range, like so

       s = "the quick brown fox jumps right over the lazy dog";
       for i,c := range(s) {
               fmt.Println(c);
       }

This will generate compiler error
amitava:go amitava$ make
6g hello.go
hello.go:36: i declared and not used
make: *** [hello.6] Error 1

FYI. This error message (declared and not used) may seem annoying at first. However, it comes in real handy when you write := instead of = somewhere and accidentally introduce a new variable instead of re-using the one you likely meant to use.

-gri 

[Gherald]

> >        s = "the quick brown fox jumps right over the lazy dog";
> >        for i,c := range(s) {
> >                fmt.Println(c);
> >        }
>
> > This will generate compiler error
> > amitava:go amitava$ make
> > 6g hello.go
> > hello.go:36: i declared and not used
> > make: *** [hello.6] Error 1
>
> FYI. This error message (declared and not used) may seem annoying at first.
> However, it comes in real handy when you write := instead of = somewhere and
> accidentally introduce a new variable instead of re-using the one you likely
> meant to use.

Shouldn't "declared but not used" be a warning rather than an error?

[Jessta]

On 13/11/2009, Gherald <ghe...@gmail.com> wrote:
> Shouldn't "declared but not used" be a warning rather than an error?
>

In this case it is very easy to fix the error and isn't something
you'd do on purpose beause there is no reason to do it. Thus it
should be an error.

Warnings should be for things that you can do and might do on purpose
but that the compiler thinks could possibly lead to an error but it's
not sure, so instead it trusts you. Those kinds of things are better
fixed in the language to prevent code of this nature from existing in
the first place rather than to throw a warning. eg. C compilers warn
about loss of precision, or using a pointer of the wrong type without
a cast or using a variable that is not initalised which really should
be impossible to do and so should all be errors.


--
=====================
http://jessta.id.au

[Gherald]

On Thu, Nov 12, 2009 at 4:33 PM, Jessta <jes...@gmail.com> wrote:

On 13/11/2009, Gherald <ghe...@gmail.com> wrote:
> Shouldn't "declared but not used" be a warning rather than an error?
>
In this case it is very easy to fix the error and isn't something
you'd do on purpose beause there is no reason to do it.

Sure there are purposeful reasons, the variable may be useful at a latter point.  In this case you might go through several revisions of coding the inner loop, some which use the variable and some which don't.

Requiring its name altered to _ or the declaration commented out may be useless make-work that only slows development.

If it doesn't break but _might_ be inadvertent then it should produce a warning, not an error.

Ditto for things that _might_ be mistakes, e.g. gri's mention of := instead of =

Resolution ought to be a requirement for commits, not compilation.

[Diego Sarmentero]

Also in this case "c" is a char, not a string, so you can not pass it to Printf just like this, you should do this:

package main

import "fmt"

func main(){
    s := "Go programming language";
    for _, c := range(s){
        fmt.Printf("%c", c)
    }
}

2009/11/12 Jessta <jes...@gmail.com>

--
Desgraciadamente Nuestra Tecnología Ha Superado Nuestra Humanidad.

-Albert Einstein-

[Gherald]

On Thu, Nov 12, 2009 at 6:40 PM, Russ Cox <r...@google.com> wrote:

If we had left things as they were before, and you had
suffered through a bug caused by typing := but meaning =,
you might have a different opinion.  We didn't introduce the
restriction lightly, but it has saved all of us multiple times
since we put it in.

I didn't suggest silently ignoring it, I think it should be a warning. Though as Rob tells us:

> We made a deliberate decision: no warnings.  If it's worth complaining about, it's worth fixing.

I don't disagree it's worth fixing, but how to best fix is something you aren't necessarily sure of at compile-time. That's where warnings come in: they let you go through various revisions before deciding (and in best-practice, committing).

I'll use your "_ = x;" override in my own toying with the language, but I would prefer warnings so I remember to fix or get rid of it later.

[Rob 'Commander' Pike]

>> Shouldn't "declared but not used" be a warning rather than an error?

We made a deliberate decision: no warnings. If it's worth complaining
about, it's worth fixing.

-rob

[Russ Cox]

> Requiring its name altered to _ or the declaration commented out may be
> useless make-work that only slows development.

There's a third way: if x is unused, add "_ = x;" and it is now used.

> Ditto for things that _might_ be mistakes, e.g. gri's mention of := instead
> of =

If we had left things as they were before, and you had
suffered through a bug caused by typing := but meaning =,
you might have a different opinion.  We didn't introduce the
restriction lightly, but it has saved all of us multiple times
since we put it in.

Requiring type declarations on function arguments is similar:
it slows down development at the microscopic level but
speeds up development at the macroscopic level by avoiding
bugs.

Russ

[hypertux]

On Nov 12, 5:54 pm, Gherald <gher...@gmail.com> wrote:
>
> Sure there are purposeful reasons, the variable may be useful at a latter
> point.  In this case you might go through several revisions of coding the
> inner loop, some which use the variable and some which don't.
>
> Requiring its name altered to _ or the declaration commented out may be
> useless make-work that only slows development.
>
> If it doesn't break but _might_ be inadvertent then it should produce a
> warning, not an error.
>
> Ditto for things that _might_ be mistakes, e.g. gri's mention of := instead
> of =
>
> Resolution ought to be a requirement for commits, not compilation.

I completely agree that there are situations where you may or may not
know whether or not a value will be needed (especially since many of
us are still just learning of this really cool new language). In those
cases, the solution for rapid testing of various scenarios is obvious:
use the variable. In other words, define some function that takes in
an 'interface{}' parameter, no return values, and has an empty body.
Then, call that function once for each variable you aren't sure about.

This way, you can ignore the variables you are "trying out", with code
that effectively does nothing except prevent the error.

All of that being said, though, I am a strong believer in designing
before writing. So, I probably wouldn't use what I just posted, and I
really hope is doesn't taint go code all of the internet. Go is a new
language, and with that comes new ways of thinking. I find myself
erasing entire blocks of code that just don't make sense with the
mechanisms provided by the language. So, before you try to turn Go
into a glorified C++/Java compiler, try to understand why decisions
were made in the language, and the reasoning behind them.

=)

[Russ Cox]

> cases, the solution for rapid testing of various scenarios is obvious:
> use the variable. In other words, define some function that takes in
> an 'interface{}' parameter, no return values, and has an empty body.
> Then, call that function once for each variable you aren't sure about.

If instead you use
_ = x;
then the compiler will not even generate any code.

Russ