FAQ
I'm sure this horse has been beat to death and served up as hamburgers
already, but I am going to throw out this realist's argument.

"if it's worth complaining about, it's worth fixing in the code" -
http://golang.org/doc/faq#unused_variables_and_imports

I don't think it's worth complaining about, at least not during the
development cycle. By now everyone knows one or more arguments for
ignoring these "errors". During development there is a lot of exploration
and temporary commenting out of blocks of code.

This hyper-strict design choice is an impediment to acceptance of the
language. A design feature of a language that causes unnecessary pain or
requires workaround effort is a bad feature.

When is this feature going to be removed? I'll bet that it will be removed
someday, so how long do we have to live with it before it gets nicer?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Minux at Mar 8, 2013 at 3:54 pm

    On Fri, Mar 8, 2013 at 11:43 PM, Michael Teter wrote:
    "if it's worth complaining about, it's worth fixing in the code" -
    http://golang.org/doc/faq#unused_variables_and_imports

    When is this feature going to be removed? I'll bet that it will be removed
    someday, so how long do we have to live with it before it gets nicer?
    There is no plans to remove that feature or its "workaround" won't even be
    mentioned in the Effective Go document.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ethan Burns at Mar 8, 2013 at 3:55 pm
    This is a non-issue. It takes no time to use the blank identifier to
    work-around unused variables while debugging
    (see http://tip.golang.org/doc/effective_go.html#blank). I greatly
    appreciate (and I know that a lot of others do too) that the Go compiler
    doesn't let me leave a bunch of nonsense code around like unused variables
    and unused imports. As you said, this has been beaten to hamburg. Please
    stop posting about it.


    Ethan
    On Friday, March 8, 2013 10:43:02 AM UTC-5, Michael Teter wrote:

    I'm sure this horse has been beat to death and served up as hamburgers
    already, but I am going to throw out this realist's argument.

    "if it's worth complaining about, it's worth fixing in the code" -
    http://golang.org/doc/faq#unused_variables_and_imports

    I don't think it's worth complaining about, at least not during the
    development cycle. By now everyone knows one or more arguments for
    ignoring these "errors". During development there is a lot of exploration
    and temporary commenting out of blocks of code.

    This hyper-strict design choice is an impediment to acceptance of the
    language. A design feature of a language that causes unnecessary pain or
    requires workaround effort is a bad feature.

    When is this feature going to be removed? I'll bet that it will be
    removed someday, so how long do we have to live with it before it gets
    nicer?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Mar 15, 2013 at 7:02 am

    On 3/8/2013 7:55 AM, Ethan Burns wrote:
    This is a non-issue.
    Agreed. This just isn't a big problem.

    Go is not being overly strict here. View this
    issue from the point of view of the maintenance programmer.

    John Nagle

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Steve McCoy at Mar 8, 2013 at 3:57 pm
    It's not a big deal. Plenty of people are using Go — more every day.

    On Friday, March 8, 2013 10:43:02 AM UTC-5, Michael Teter wrote:

    I'm sure this horse has been beat to death and served up as hamburgers
    already, but I am going to throw out this realist's argument.

    "if it's worth complaining about, it's worth fixing in the code" -
    http://golang.org/doc/faq#unused_variables_and_imports

    I don't think it's worth complaining about, at least not during the
    development cycle. By now everyone knows one or more arguments for
    ignoring these "errors". During development there is a lot of exploration
    and temporary commenting out of blocks of code.

    This hyper-strict design choice is an impediment to acceptance of the
    language. A design feature of a language that causes unnecessary pain or
    requires workaround effort is a bad feature.

    When is this feature going to be removed? I'll bet that it will be
    removed someday, so how long do we have to live with it before it gets
    nicer?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nate Finch at Mar 8, 2013 at 4:55 pm

    On Friday, March 8, 2013 10:43:02 AM UTC-5, Michael Teter wrote:

    I'm sure this horse has been beat to death

    Yes, it has.

    During development there is a lot of exploration and temporary
    commenting out of blocks of code.
    That's your practice, perhaps. Many people don't do that. Personally, I
    never do that.

    This hyper-strict design choice is an impediment to acceptance of the
    language.
    ...by you? I don't think you can speak for the world of programmers in
    general.

    A design feature of a language that causes unnecessary pain or requires
    workaround effort is a bad feature.
    Most of us find it to be a helpful feature for keeping our code clean and
    pointing out potential bugs in our code. Seriously, if people like you
    hadn't complained about it, it never would have occurred to me to think of
    it as anything other than just another compiler error message, like
    unreachable code or incompatible integer types.

    When is this feature going to be removed? I'll bet that it will be
    removed someday, so how long do we have to live with it before it gets
    nicer?
    If it is ever removed I will be completely flabbergasted.

    I mean this in the most non-confrontational way possible: are you coming
    from a mainly interpreted language background? It seems that the people who
    complain about the compiler errors the most are those who are not used to
    using a compiler at all.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sam Harwell at Mar 8, 2013 at 7:08 pm
    Hi Nate,

    I think this behavior is particularly noticeable to people with experience working with the Microsoft compilers as well. They group compiler errors by relative severity (Error, the Warning Levels 1-4 in order). The Go compiler behaves similar to what you get if you set the reporting level to (for C#) /warn:4 /warnaserror.

    I do wish the Go compiler separated its errors by severity, assigned numbers to them, and allowed errors at some severity levels to be treated as warnings (including the one addressed by this thread and the error concerning unused imports). As-is, when a compiler error occurs there is no immediate indication of whether I actually did something wrong or just did something that someone arbitrarily decided to not allow, even though allowing it would have no impact on the semantics of the language.

    It seems most people would be happy if:


    1. The compiler was able to classify messages as "errors" or "warnings"

    2. All current messages were given the initial severity of "error", with the exception of the unused assignment and unused import messages

    3. A compiler flag to treat warnings as errors was added and enabled by default (or perhaps have a flag to not treat warnings as errors instead)

    This would preserve the current behavior for general development while addressing the concerns of developers who have expressed a preference for differing approaches to product development.

    Thank you,
    --
    Sam Harwell
    Owner, Lead Developer
    http://tunnelvisionlabs.com

    From: golang-nuts@googlegroups.com On Behalf Of Nate Finch
    Sent: Friday, March 08, 2013 10:56 AM
    To: golang-nuts@googlegroups.com
    Subject: [go-nuts] Re: one button mice and compiler errors on unused variables

    If it is ever removed I will be completely flabbergasted.

    I mean this in the most non-confrontational way possible: are you coming from a mainly interpreted language background? It seems that the people who complain about the compiler errors the most are those who are not used to using a compiler at all.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gauravk at Mar 8, 2013 at 7:45 pm
    Here I am working on Java code written over last few years by many
    experienced developers. It is full of unused imports, unused variables and
    poorly formatted. Now IBM rational app developer is used here, and all of
    issues mentioned can be taken care of with the help of tool, but it is
    never done by anyone who worked on this code base. It says something about
    tools and user of tools.

    In my view Go has made a great decision ( apart from lots of others) on
    this warning/ error issue. A lot of people would have been happier if
    iphone ran flash but now we know better. The conviction of Go authors is
    about language design is matter of great satisfaction to me.

    Thanks
    On Friday, March 8, 2013 2:08:23 PM UTC-5, Sam Harwell wrote:

    Hi Nate,



    I think this behavior is particularly noticeable to people with experience
    working with the Microsoft compilers as well. They group compiler errors by
    relative severity (Error, the Warning Levels 1-4 in order). The Go compiler
    behaves similar to what you get if you set the reporting level to (for C#)
    /warn:4 /warnaserror.



    I do wish the Go compiler separated its errors by severity, assigned
    numbers to them, and allowed errors at some severity levels to be treated
    as warnings (including the one addressed by this thread and the error
    concerning unused imports). As-is, when a compiler error occurs there is no
    immediate indication of whether I actually did something wrong or just did
    something that someone arbitrarily decided to not allow, even though
    allowing it would have no impact on the semantics of the language.



    It seems most people would be happy if:



    1. The compiler was able to classify messages as “errors” or
    “warnings”

    2. All current messages were given the initial severity of “error”,
    with the exception of the unused assignment and unused import messages

    3. A compiler flag to treat warnings as errors was added and
    enabled by default (or perhaps have a flag to *not* treat warnings as
    errors instead)



    This would preserve the current behavior for general development while
    addressing the concerns of developers who have expressed a preference for
    differing approaches to product development.



    Thank you,

    --

    Sam Harwell

    Owner, Lead Developer

    http://tunnelvisionlabs.com



    *From:* golan...@googlegroups.com <javascript:> [mailto:
    golan...@googlegroups.com <javascript:>] *On Behalf Of *Nate Finch
    *Sent:* Friday, March 08, 2013 10:56 AM
    *To:* golan...@googlegroups.com <javascript:>
    *Subject:* [go-nuts] Re: one button mice and compiler errors on unused
    variables



    If it is ever removed I will be completely flabbergasted.



    I mean this in the most non-confrontational way possible: are you coming
    from a mainly interpreted language background? It seems that the people who
    complain about the compiler errors the most are those who are not used to
    using a compiler at all.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Pike at Mar 8, 2013 at 8:41 pm

    On Fri, Mar 8, 2013 at 11:08 AM, Sam Harwell wrote:

    This would preserve the current behavior for general development while
    addressing the concerns of developers who have expressed a preference for
    differing approaches to product development.
    One of the overriding ideas behind Go was to narrow the possibilities
    for software development by taking a strong position on many issues.
    This is one of them. You're asking for a feature that violates the
    philosophy of the language. Classes of errors lead to dialects of the
    language. That would be a terrible outcome. We want every Go
    programmer to use the same language.

    The topic of warnings vs. errors has been discussed many times on the
    list. It will probably come up many more. But the decision, which in
    time you may come to appreciate, will not change.

    -rob

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jeremy Wall at Mar 8, 2013 at 10:57 pm
    The one thing that I love about Go more than anything else is that the
    language is opinionated. Even if I don't agree with the opinion the fact
    that it has an opinion is something I value. I happen to agree with this
    particular opinion but even if I didn't I'm still happy Go has it.

    It lowers my cognitive overhead. There is a whole class of errors I don't
    have to think about anymore. When Go tells me something is wrong there is a
    high likelihood that I will know exactly where to go to fix it.
    That is more important to me than convenience in editing. I can fix
    convenience issues in editing. It's way harder to fix ambiguity in the
    language.

    On Fri, Mar 8, 2013 at 2:41 PM, Rob Pike wrote:
    On Fri, Mar 8, 2013 at 11:08 AM, Sam Harwell wrote:

    This would preserve the current behavior for general development while
    addressing the concerns of developers who have expressed a preference for
    differing approaches to product development.
    One of the overriding ideas behind Go was to narrow the possibilities
    for software development by taking a strong position on many issues.
    This is one of them. You're asking for a feature that violates the
    philosophy of the language. Classes of errors lead to dialects of the
    language. That would be a terrible outcome. We want every Go
    programmer to use the same language.

    The topic of warnings vs. errors has been discussed many times on the
    list. It will probably come up many more. But the decision, which in
    time you may come to appreciate, will not change.

    -rob

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Herbert Fischer at Mar 14, 2013 at 7:06 pm
    I think kind of answer should be like a "fixed topic" somewhere, maybe
    in the QA, or maybe a dedicated page in golang.org (Thinks golang is
    not going to have, never, and why).

    Just like a billboard waiting for someone to scratch their itches.
    On 8 March 2013 17:41, Rob Pike wrote:
    On Fri, Mar 8, 2013 at 11:08 AM, Sam Harwell wrote:

    This would preserve the current behavior for general development while
    addressing the concerns of developers who have expressed a preference for
    differing approaches to product development.
    One of the overriding ideas behind Go was to narrow the possibilities
    for software development by taking a strong position on many issues.
    This is one of them. You're asking for a feature that violates the
    philosophy of the language. Classes of errors lead to dialects of the
    language. That would be a terrible outcome. We want every Go
    programmer to use the same language.

    The topic of warnings vs. errors has been discussed many times on the
    list. It will probably come up many more. But the decision, which in
    time you may come to appreciate, will not change.

    -rob

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nate Finch at Mar 9, 2013 at 2:24 am

    On Friday, March 8, 2013 2:08:23 PM UTC-5, Sam Harwell wrote:

    I think this behavior is particularly noticeable to people with
    experience working with the Microsoft compilers as well. They group
    compiler errors by relative severity (Error, the Warning Levels 1-4 in
    order). The Go compiler behaves similar to what you get if you set the
    reporting level to (for C#) /warn:4 /warnaserror.
    When I joined my current company several years ago (a C# / Visual Studio
    shop), the main solution had hundreds of warnings. Half the time you
    couldn't see the errors because of all the warnings. One of the first
    things I did there was to set warnings as errors to true on all the
    projects. I spent a week going through the source and cleaning up all the
    bad code that was causing the warnings. The code has stayed that way ever
    since.. and it is cleaner and less buggy because of it.

    Moral of the story: if you let programmers ignore errors, they will, and
    not just temporarily, but forever.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Roger peppe at Mar 9, 2013 at 5:54 am
    yes, the warnings are annoying.

    but in my experience, as often as not the warnings actually catch real bugs.
    ironically, i think this happens *more* often in code exploration mode,
    when one is trying to hack out as quickly as possible, and an error caught
    early can save considerable time.

    i think the resulting cleanliness and the relevant errors are worth
    the extra editing work.
    On 8 March 2013 21:23, Nate Finch wrote:
    On Friday, March 8, 2013 2:08:23 PM UTC-5, Sam Harwell wrote:

    I think this behavior is particularly noticeable to people with experience
    working with the Microsoft compilers as well. They group compiler errors by
    relative severity (Error, the Warning Levels 1-4 in order). The Go compiler
    behaves similar to what you get if you set the reporting level to (for C#)
    /warn:4 /warnaserror.
    When I joined my current company several years ago (a C# / Visual Studio
    shop), the main solution had hundreds of warnings. Half the time you
    couldn't see the errors because of all the warnings. One of the first things
    I did there was to set warnings as errors to true on all the projects. I
    spent a week going through the source and cleaning up all the bad code that
    was causing the warnings. The code has stayed that way ever since.. and it
    is cleaner and less buggy because of it.

    Moral of the story: if you let programmers ignore errors, they will, and not
    just temporarily, but forever.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Mar 8, 2013 at 10:42 pm

    On Friday, March 8, 2013 9:55:51 AM UTC-7, Nate Finch wrote:
    On Friday, March 8, 2013 10:43:02 AM UTC-5, Michael Teter wrote:

    During development there is a lot of exploration and temporary
    commenting out of blocks of code.
    That's your practice, perhaps. Many people don't do that. Personally, I
    never do that.
    I do that very occasionally, but when I do find that these errors actually
    aid exploration, since it highlights variable relationships and flow. It's
    really a tooling issue: if you're jumping out of an editor, compiling,
    getting the error, then jumping back into the editor, repeat, then just
    about any development in a compiler based language (or anything that
    doesn't allow live code editing) is going to be painful -- this issue can
    be mitigated by using an automatic recompile wrapper that watches your
    source files, or even just firing off a compile && run script from another
    shell any time you want to see output. Go compiles quickly enough that such
    things cease to be annoyances if handled properly.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Bryanturley at Mar 8, 2013 at 5:38 pm

    On Friday, March 8, 2013 9:43:02 AM UTC-6, Michael Teter wrote:
    I'm sure this horse has been beat to death and served up as hamburgers
    already, but I am going to throw out this realist's argument.

    "if it's worth complaining about, it's worth fixing in the code" -
    http://golang.org/doc/faq#unused_variables_and_imports

    I don't think it's worth complaining about, at least not during the
    development cycle. By now everyone knows one or more arguments for
    ignoring these "errors". During development there is a lot of exploration
    and temporary commenting out of blocks of code.

    This hyper-strict design choice is an impediment to acceptance of the
    language.
    Or it weeds out the whiners.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chris dollin at Mar 8, 2013 at 6:17 pm
    Could we please not play the implied insult game?

    Chris, onna Nexus.
    On Mar 8, 2013 5:38 PM, "bryanturley" wrote:


    On Friday, March 8, 2013 9:43:02 AM UTC-6, Michael Teter wrote:

    I'm sure this horse has been beat to death and served up as hamburgers
    already, but I am going to throw out this realist's argument.

    "if it's worth complaining about, it's worth fixing in the code" -
    http://golang.org/doc/faq#**unused_variables_and_imports<http://golang.org/doc/faq#unused_variables_and_imports>

    I don't think it's worth complaining about, at least not during the
    development cycle. By now everyone knows one or more arguments for
    ignoring these "errors". During development there is a lot of exploration
    and temporary commenting out of blocks of code.

    This hyper-strict design choice is an impediment to acceptance of the
    language.
    Or it weeds out the whiners.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Bryanturley at Mar 8, 2013 at 6:32 pm

    On Friday, March 8, 2013 12:17:35 PM UTC-6, chris dollin wrote:
    Could we please not play the implied insult game?

    Chris, onna Nexus.
    No insult was implied. But I am withholding a few for you.

    On Mar 8, 2013 5:38 PM, "bryanturley" <bryan...@gmail.com <javascript:>>
    wrote:
    On Friday, March 8, 2013 9:43:02 AM UTC-6, Michael Teter wrote:

    I'm sure this horse has been beat to death and served up as hamburgers
    already, but I am going to throw out this realist's argument.

    "if it's worth complaining about, it's worth fixing in the code" -
    http://golang.org/doc/faq#**unused_variables_and_imports<http://golang.org/doc/faq#unused_variables_and_imports>

    I don't think it's worth complaining about, at least not during the
    development cycle. By now everyone knows one or more arguments for
    ignoring these "errors". During development there is a lot of exploration
    and temporary commenting out of blocks of code.

    This hyper-strict design choice is an impediment to acceptance of the
    language.
    Or it weeds out the whiners.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nicolas Sebrecht at Mar 13, 2013 at 9:09 pm

    On Fri, Mar 08, 2013 at 07:43:02AM -0800, Michael Teter wrote:

    I'm sure this horse has been beat to death and served up as hamburgers
    already, but I am going to throw out this realist's argument.

    "if it's worth complaining about, it's worth fixing in the code" -
    http://golang.org/doc/faq#unused_variables_and_imports

    I don't think it's worth complaining about, at least not during the
    development cycle. By now everyone knows one or more arguments for
    ignoring these "errors". During development there is a lot of exploration
    and temporary commenting out of blocks of code.

    This hyper-strict design choice is an impediment to acceptance of the
    language. A design feature of a language that causes unnecessary pain or
    requires workaround effort is a bad feature.
    Plain true. Having to deal with workarounds like that sightly distracts
    from the development process. Being repeatedly dealing with such
    compiler policy is time consuming because it moves the focus on
    unrelevant issues, far away from the business code/logic which really
    matters.

    Having to mention a workaround in the faq is already a way to admit
    that this strong policy is wrong.

    The missing argument of the compiler to turn such errors into warning is
    what keeps me still away from go. I think very few people not using go
    anymore like me are still following this mailing list to talk about this
    issue.

    What does the workaround, seriously? It helps you to keep unused
    variables and imports inside the code. Just as warnings would do.
    How is that so different from just commenting some code I'm currently
    playing with and let unused stuff as-is? Nothing, but the pain of the
    distraction.

    So, yes. I fully agree with you. This is unnecessary annoyance. Do the
    developers always write in go in one shot exactly like gofmt would
    format the code? Of course not. It is expected to reformat _once_ the
    business logic is implemented and ready to be polished. The same policy
    should apply for unused variables and imports: let the devs focus on
    valuable considerations before helping him to clean the code.

    Allowing to compile code with light policy around non-fatal errors makes
    sense. The purpose is only to allow doing bad things WHILE hacking in
    order to help working on experimental code. This is exaclty what helps
    to gain productivity. I think it matters as much as compilation time, at
    least.
    When is this feature going to be removed? I'll bet that it will be removed
    someday, so how long do we have to live with it before it gets nicer?
    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Mar 13, 2013 at 10:03 pm

    So, yes. I fully agree with you. This is unnecessary annoyance. Do the
    developers always write in go in one shot exactly like gofmt would
    format the code?
    Yes, actually. You'd be surprised how quickly the regularity of the
    grammar of the language allows you write pages of text that compiles
    first time without the need for a burdensome IDE.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jackie Li at Mar 13, 2013 at 10:48 pm
    Hi,


    I'm still get bitten by this from time to time, especially when I try out
    some new ideas and want to finish the code logic fast.

    But after a while of coding with this annoyance, and thinking back, I find
    it actually helps me.

    I highly recommend you to bear this minor annoyance, carry it on for a
    while, and see if it's really bad or good for you.


    Cheers,
    Jackie

    On Wed, Mar 13, 2013 at 10:09 PM, Nicolas Sebrecht wrote:
    On Fri, Mar 08, 2013 at 07:43:02AM -0800, Michael Teter wrote:

    I'm sure this horse has been beat to death and served up as hamburgers
    already, but I am going to throw out this realist's argument.

    "if it's worth complaining about, it's worth fixing in the code" -
    http://golang.org/doc/faq#unused_variables_and_imports

    I don't think it's worth complaining about, at least not during the
    development cycle. By now everyone knows one or more arguments for
    ignoring these "errors". During development there is a lot of
    exploration
    and temporary commenting out of blocks of code.

    This hyper-strict design choice is an impediment to acceptance of the
    language. A design feature of a language that causes unnecessary pain or
    requires workaround effort is a bad feature.
    Plain true. Having to deal with workarounds like that sightly distracts
    from the development process. Being repeatedly dealing with such
    compiler policy is time consuming because it moves the focus on
    unrelevant issues, far away from the business code/logic which really
    matters.

    Having to mention a workaround in the faq is already a way to admit
    that this strong policy is wrong.

    The missing argument of the compiler to turn such errors into warning is
    what keeps me still away from go. I think very few people not using go
    anymore like me are still following this mailing list to talk about this
    issue.

    What does the workaround, seriously? It helps you to keep unused
    variables and imports inside the code. Just as warnings would do.
    How is that so different from just commenting some code I'm currently
    playing with and let unused stuff as-is? Nothing, but the pain of the
    distraction.

    So, yes. I fully agree with you. This is unnecessary annoyance. Do the
    developers always write in go in one shot exactly like gofmt would
    format the code? Of course not. It is expected to reformat _once_ the
    business logic is implemented and ready to be polished. The same policy
    should apply for unused variables and imports: let the devs focus on
    valuable considerations before helping him to clean the code.

    Allowing to compile code with light policy around non-fatal errors makes
    sense. The purpose is only to allow doing bad things WHILE hacking in
    order to help working on experimental code. This is exaclty what helps
    to gain productivity. I think it matters as much as compilation time, at
    least.
    When is this feature going to be removed? I'll bet that it will be removed
    someday, so how long do we have to live with it before it gets nicer?
    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Jackie

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Carlos Castillo at Mar 13, 2013 at 11:51 pm
    I agree, after coding for almost a year in go, I have found that
    I subconsciously make better decisions when writing code, even in other
    languages because of the strictness of the go compiler.

    Whenever I think of this I remember my lessons when being taught Perl and
    VB: always turn on the strict compile mode, otherwise you will make stupid
    mistakes, and not find out about it until later.
    On Wednesday, March 13, 2013 3:47:39 PM UTC-7, Jackie wrote:

    Hi,


    I'm still get bitten by this from time to time, especially when I try out
    some new ideas and want to finish the code logic fast.

    But after a while of coding with this annoyance, and thinking back, I find
    it actually helps me.

    I highly recommend you to bear this minor annoyance, carry it on for a
    while, and see if it's really bad or good for you.


    Cheers,
    Jackie


    On Wed, Mar 13, 2013 at 10:09 PM, Nicolas Sebrecht <nicola...@laposte.net<javascript:>
    wrote:
    On Fri, Mar 08, 2013 at 07:43:02AM -0800, Michael Teter wrote:

    I'm sure this horse has been beat to death and served up as hamburgers
    already, but I am going to throw out this realist's argument.

    "if it's worth complaining about, it's worth fixing in the code" -
    http://golang.org/doc/faq#unused_variables_and_imports

    I don't think it's worth complaining about, at least not during the
    development cycle. By now everyone knows one or more arguments for
    ignoring these "errors". During development there is a lot of
    exploration
    and temporary commenting out of blocks of code.

    This hyper-strict design choice is an impediment to acceptance of the
    language. A design feature of a language that causes unnecessary pain or
    requires workaround effort is a bad feature.
    Plain true. Having to deal with workarounds like that sightly distracts
    from the development process. Being repeatedly dealing with such
    compiler policy is time consuming because it moves the focus on
    unrelevant issues, far away from the business code/logic which really
    matters.

    Having to mention a workaround in the faq is already a way to admit
    that this strong policy is wrong.

    The missing argument of the compiler to turn such errors into warning is
    what keeps me still away from go. I think very few people not using go
    anymore like me are still following this mailing list to talk about this
    issue.

    What does the workaround, seriously? It helps you to keep unused
    variables and imports inside the code. Just as warnings would do.
    How is that so different from just commenting some code I'm currently
    playing with and let unused stuff as-is? Nothing, but the pain of the
    distraction.

    So, yes. I fully agree with you. This is unnecessary annoyance. Do the
    developers always write in go in one shot exactly like gofmt would
    format the code? Of course not. It is expected to reformat _once_ the
    business logic is implemented and ready to be polished. The same policy
    should apply for unused variables and imports: let the devs focus on
    valuable considerations before helping him to clean the code.

    Allowing to compile code with light policy around non-fatal errors makes
    sense. The purpose is only to allow doing bad things WHILE hacking in
    order to help working on experimental code. This is exaclty what helps
    to gain productivity. I think it matters as much as compilation time, at
    least.
    When is this feature going to be removed? I'll bet that it will be removed
    someday, so how long do we have to live with it before it gets nicer?
    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Jackie
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Teter at Mar 14, 2013 at 10:05 am
    I will concede that after adapting to the Go way, one may do things better
    the first time. But one may also do it slower the first time - in the same
    time as the explorer iterates through two or three versions, complete with
    temporary unused variables appearing and then likely disappearing.

    *I think that an official language FAQ that describes how to work around an
    artificially imposed (at least, not strictly necessary) barrier is an
    indication of a flaw in the design.*

    What is to prevent someone (or an IDE) from automatically adding _ =
    myPotentiallyUnusedVar after the declaration of every variable?

    I find it amusing that the FAQ even includes the comment TODO: delete
    before committing!

    "In the old days", we had periodic code reviews. That's where you sat with
    your team or even non-technical people outside your team and gave them a
    walk through your code. It's also where you might see if you were being
    wasteful or if you had left cruft behind. Some of us even do that by
    ourselves once in a while (like before going into production).

    My point here is that this compiler error is an intentional artificial
    barrier that will limit the acceptance of the language. And in some cases,
    it will be the cause of _ = foo crap left in code.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at Mar 14, 2013 at 10:20 am
    On Thu, Mar 14, 2013 at 11:05 AM, Michael Teter wrote:

    The unused variable error is a specific, one of many others, language
    design choice. Calling it other names, like "artificial barrier" of
    whatever cannot change that fact. Also "will limit the acceptance of
    the language" is an opinion, not a measured data point (aka this way
    one can claim just about anything without taking the risk of it being
    falsified easily/at all).

    IOW, have you some interesting observation and/or improvement/change
    proposal about this discussed language design choice?

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Teter at Mar 14, 2013 at 11:10 am
    It is an artificially imposed barrier. The existence of an unused variable
    is essentially irrelevant to the computer. Sure there may be a tiny memory
    cost as well as a small compiling overhead, but the same could be said for
    variables and functions with long names (if we want to be picky).

    Language acceptance does matter. I'm not suggesting that Go try to be
    everything to all people, but it should be consistent in its strictness.
    Clearly effort has been put into making sure that code is formatted
    uniformly (gofmt), so why not golint and have obvious cruft removed for
    you?

    I'm not here to argue or whine, but I am calling out what I think is a
    mistake in the design - one that's obvious enough and presumably simple
    enough that it should be fixed.

    My proposal would be to either make it a warning, or (if warnings are still
    verboten) instead just stop complaining and let gofmt or a lint clean it up.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Mar 14, 2013 at 11:15 am
    You are confusing the format of the source code (what you call gofmt),
    which is at most a convention to avoid pointless arguments about
    indentation, and the syntax of the language. Go is an opinionated
    language. Those opinions were spelled out in November of 2009 and have
    not changed substantially since.
    On Thu, Mar 14, 2013 at 10:10 PM, Michael Teter wrote:
    It is an artificially imposed barrier. The existence of an unused variable
    is essentially irrelevant to the computer. Sure there may be a tiny memory
    cost as well as a small compiling overhead, but the same could be said for
    variables and functions with long names (if we want to be picky).

    Language acceptance does matter. I'm not suggesting that Go try to be
    everything to all people, but it should be consistent in its strictness.
    Clearly effort has been put into making sure that code is formatted
    uniformly (gofmt), so why not golint and have obvious cruft removed for you?

    I'm not here to argue or whine, but I am calling out what I think is a
    mistake in the design - one that's obvious enough and presumably simple
    enough that it should be fixed.

    My proposal would be to either make it a warning, or (if warnings are still
    verboten) instead just stop complaining and let gofmt or a lint clean it up.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Roger peppe at Mar 14, 2013 at 1:40 pm

    On 14 March 2013 11:10, Michael Teter wrote:
    My proposal would be to either make it a warning, or (if warnings are still
    verboten) instead just stop complaining and let gofmt or a lint clean it up.
    Cleaning it up would just hide the bugs that this error often exposes.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Jones at Mar 14, 2013 at 2:55 pm
    Hi Michael (from another Michael ;-)

    Yes, it certainly *is* an artificially imposed barrier. The compiler need
    not care. Go has quite a few of these: you can't import packages that you
    don't use, you can't import packages twice and have redundancy ignored, you
    can't define variables that you don't use; you can't add a smaller-sized
    unsigned integer and a larger-sized unsigned integer without an explicit
    type cast, and many more.

    Several people have explained that *Go is an opinionated language* or
    equivalently, that *Go has an attitude*. What informs Go's opinions? Where
    does its attitude come from? These questions are easy to overlook because
    Turing completeness trumps a language's underlying theses* so we're not in
    the habit of asking such questions. Yet, the questions are important and
    more so if they differ from our experience. Go's answers are given here by
    Rob Pike:

    http://talks.golang.org/2012/splash.slide#1


    This is a good presentation, I hope you'll read or view it carefully. It
    will help you know if Go is comfortable for your situation. It will
    certainly explain *why* the discomforts you describe above are as they are.
    It will also explain why some of the emails above sound like "yes, it hurts
    a little, but it's good for you, and you get used to it." You may even come
    to look back some day and say, "I'm a better programmer now, both in the
    small solo projects and in large team efforts, thanks to Go's opinions and
    attitudes." I sure hope so.

    Michael Jones

    * The typical thesis is usually more about computers and computation than
    about software engineering as a group activity. FORTRAN's is "efficiently
    evaluate numerical equations," Java's is "universal portability," and C's
    is "efficient abstraction of hardware specifics." Research languages by
    definition have a thesis about specific ideas like FP's "explore the
    functional computing paradigm" or LISP's "unify code and data."

    On Thu, Mar 14, 2013 at 6:19 AM, roger peppe wrote:
    On 14 March 2013 11:10, Michael Teter wrote:
    My proposal would be to either make it a warning, or (if warnings are still
    verboten) instead just stop complaining and let gofmt or a lint clean it
    up.

    Cleaning it up would just hide the bugs that this error often exposes.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Roger peppe at Mar 14, 2013 at 10:51 am

    On 14 March 2013 10:05, Michael Teter wrote:
    I will concede that after adapting to the Go way, one may do things better
    the first time. But one may also do it slower the first time - in the same
    time as the explorer iterates through two or three versions, complete with
    temporary unused variables appearing and then likely disappearing.
    Being aware of this issue, I like to keep an eye on how much this happens
    and for what reasons.

    Sometimes the unused variable is one I will use again in the future, it's
    true, but it seems like just as often it's actually a bug that I've missed
    when refactoring, and in my experience little bugs like that can really
    slow down the iteration process.

    The _ workarounds are good when there really is a variable or package
    which comes and goes repeatedly. I don't believe that's actually as common as
    you make out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nicolas Sebrecht at Mar 14, 2013 at 5:20 pm

    On Wed, Mar 13, 2013 at 04:51:04PM -0700, Carlos Castillo wrote:

    I agree, after coding for almost a year in go, I have found that
    I subconsciously make better decisions when writing code, even in other
    languages because of the strictness of the go compiler.
    The strictness of the go compiler is definetly not the issue. The
    problem is the time chosen to apply the strong policy.

    Maybe introducing a new tool would hurt less than a compiler option.

    # go help hack
    usage: go hack [-o output] [build flags] [packages]

    Compile packages and dependencies.

    Turn some non-fatal errors into warnings to help productivity while
    working on experimental stuff. As this tool allows poor programming
    practices, it is highly expected to finish the development task with go
    build.
    Never use it outside a local and experimental use case.

    See 'go help build' for more information on arguments.
    #

    This way, go build would keep the strong compiler policy.

    Think of it again: underscores do exactly what you could get with
    warnings: keep unused stuff in the code and continue to hack. But having
    to set underscore for each unused stuff is boring and counter-productive
    while I want to focus on the code logic.

    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Volker Dobler at Mar 14, 2013 at 5:37 pm

    Am Donnerstag, 14. März 2013 18:20:54 UTC+1 schrieb Nicolas Sebrecht:

    On Wed, Mar 13, 2013 at 04:51:04PM -0700, Carlos Castillo wrote:

    Never use it outside a local and experimental use case.
    Printing this line and hoping such debug stuff won't make it to prod
    because "it was clearly stated" is what does not work in reality.

    Let's face reality. Get used to strict compilers.

    (It's worth googeling how they code for the mars rover at JET:
    Not _any_ warning from _any_ compiler or _any_ code
    analysis tool is allowed. Period. And I think they know why.)

    V.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sam Harwell at Mar 14, 2013 at 5:55 pm
    Your reality (suggesting that compiler "warnings" will eventually be things of the past) is not quite reality, even with Go.

    The actual reality is, if Go were ever widely adopted then it would not be long before an alternate build/fork of the compiler would soon surface which included the ability to distinguish between illegal code (no unambiguous compiled semantics) and the compiler's "opinions." I am confident of this for the following reasons:


    1. Go's compiler is open source and the license permits such alteration

    2. If not already done by someone else, I plan personally create the fork (perhaps for internal use only) the next time we get a contract working with a Go project. Naturally our deliverables would compile without warnings, but we are highly productive during rapid prototyping and the Go compiler proved extremely cumbersome in practice last time we were working with it.


    --
    Sam Harwell
    Owner, Lead Developer
    http://tunnelvisionlabs.com

    From: golang-nuts@googlegroups.com On Behalf Of Volker Dobler
    Sent: Thursday, March 14, 2013 12:38 PM
    To: golang-nuts@googlegroups.com
    Cc: Carlos Castillo; Nicolas Sebrecht; Michael Teter; nicolas.s-dev@laposte.net
    Subject: Re: [go-nuts] Re: one button mice and compiler errors on unused variables

    Am Donnerstag, 14. März 2013 18:20:54 UTC+1 schrieb Nicolas Sebrecht:
    On Wed, Mar 13, 2013 at 04:51:04PM -0700, Carlos Castillo wrote:

    Never use it outside a local and experimental use case.

    Printing this line and hoping such debug stuff won't make it to prod
    because "it was clearly stated" is what does not work in reality.

    Let's face reality. Get used to strict compilers.

    (It's worth googeling how they code for the mars rover at JET:
    Not _any_ warning from _any_ compiler or _any_ code
    analysis tool is allowed. Period. And I think they know why.)

    V.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com .
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brendan Tracey at Mar 14, 2013 at 6:13 pm
    For what it's worth, I too would like to see an option added. Whether
    that's a compiler flag, or a different tool doesn't matter to me. By the
    time I'm done coding I plan on using the normal go run/build/install .
    Making a tool called "go hack" makes it clear that you aren't supposed to
    use it for working code.

    Robert, I have been keeping stats on my own usage, and for me it's
    overwhelmingly in favor of things that I plan to change, whether that's
    variables I will put back in, packages I will put back in, or packages I
    thought I needed but no longer need. It's rare that this error catches a
    bug for me. Perhaps that's just me, but something to add to your stats.

    I do really like the error for the standard compiler, but I wish I could
    turn it off while I know my code is in flux (for example, when debugging).

    >

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nicolas Sebrecht at Mar 14, 2013 at 7:35 pm

    On Thu, Mar 14, 2013 at 05:55:50PM +0000, Sam Harwell wrote:
    Your reality (suggesting that compiler "warnings" will eventually be things of the past) is not quite reality, even with Go.

    The actual reality is, if Go were ever widely adopted then it would not be long before an alternate build/fork of the compiler would soon surface which included the ability to distinguish between illegal code (no unambiguous compiled semantics) and the compiler's "opinions." I am confident of this for the following reasons:


    1. Go's compiler is open source and the license permits such alteration

    2. If not already done by someone else, I plan personally create the fork (perhaps for internal use only) the next time we get a contract working with a Go project. Naturally our deliverables would compile without warnings, but we are highly productive during rapid prototyping and the Go compiler proved extremely cumbersome in practice last time we were working with it.
    If such initiative is made public I would be one of the users. Honestly,
    I would even be very happy with only floating patches to apply on my
    own. ;-)

    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nicolas Sebrecht at Mar 15, 2013 at 4:55 pm

    On Thu, Mar 14, 2013 at 09:35:32PM +0100, Nicolas Sebrecht wrote:
    On Thu, Mar 14, 2013 at 05:55:50PM +0000, Sam Harwell wrote:

    1. Go's compiler is open source and the license permits such alteration

    2. If not already done by someone else, I plan personally create the fork (perhaps for internal use only) the next time we get a contract working with a Go project. Naturally our deliverables would compile without warnings, but we are highly productive during rapid prototyping and the Go compiler proved extremely cumbersome in practice last time we were working with it.
    If such initiative is made public I would be one of the users. Honestly,
    I would even be very happy with only floating patches to apply on my
    own. ;-)
    Here is a starting point. The current patch turns compiler errors for unused
    stuff into warnings. It looks to work fine for me. Not widely tested, yet.

    Also, the patch definetly turns errors into warnings. No option is exposed to
    the user.

    Now, I'll be happy to hack with go. ,-)

    Applies fine on top of go1.0.3 (changeset 16127:70d1d0a4bcab to be exact).


    diff -r d5666bad617d src/cmd/gc/lex.c
    --- a/src/cmd/gc/lex.c Thu Sep 27 15:36:22 2012 -0700
    +++ b/src/cmd/gc/lex.c Fri Mar 15 18:47:10 2013 +0100
    @@ -2200,7 +2200,7 @@
    // errors if a conflicting top-level name is
    // introduced by a different file.
    if(!s->def->used && !nsyntaxerrors)
    - yyerrorl(s->def->lineno, "imported and not used: \"%Z\"", s->def->pkg->path);
    + warnl(s->def->lineno, "imported and not used: \"%Z\"", s->def->pkg->path);
    s->def = N;
    continue;
    }
    @@ -2208,7 +2208,7 @@
    // throw away top-level name left over
    // from previous import . "x"
    if(s->def->pack != N && !s->def->pack->used && !nsyntaxerrors) {
    - yyerrorl(s->def->pack->lineno, "imported and not used: \"%Z\"", s->def->pack->pkg->path);
    + warnl(s->def->pack->lineno, "imported and not used: \"%Z\"", s->def->pack->pkg->path);
    s->def->pack->used = 1;
    }
    s->def = N;
    diff -r d5666bad617d src/cmd/gc/subr.c
    --- a/src/cmd/gc/subr.c Thu Sep 27 15:36:22 2012 -0700
    +++ b/src/cmd/gc/subr.c Fri Mar 15 18:47:10 2013 +0100
    @@ -400,7 +400,7 @@
    }
    if(n == 0) {
    // can't possibly be used - there were no symbols
    - yyerrorl(pack->lineno, "imported and not used: \"%Z\"", opkg->path);
    + warnl(pack->lineno, "imported and not used: \"%Z\"", opkg->path);
    }
    }

    diff -r d5666bad617d src/cmd/gc/walk.c
    --- a/src/cmd/gc/walk.c Thu Sep 27 15:36:22 2012 -0700
    +++ b/src/cmd/gc/walk.c Fri Mar 15 18:47:10 2013 +0100
    @@ -94,11 +94,11 @@
    if(l->n->defn->left->used)
    continue;
    lineno = l->n->defn->left->lineno;
    - yyerror("%S declared and not used", l->n->sym);
    + warn("%S declared and not used", l->n->sym);
    l->n->defn->left->used = 1; // suppress repeats
    } else {
    lineno = l->n->lineno;
    - yyerror("%S declared and not used", l->n->sym);
    + warn("%S declared and not used", l->n->sym);
    }
    }

    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Aram Hăvărneanu at Mar 15, 2013 at 5:02 pm
    I'm not laughing.

    --
    Aram Hăvărneanu

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at Mar 15, 2013 at 5:13 pm

    On Fri, Mar 15, 2013 at 6:01 PM, Aram Hăvărneanu wrote:
    I'm not laughing.
    This is indeed a quite sad moment.

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Daniel Morsing at Mar 15, 2013 at 5:19 pm
    By throwing away imported and not used errors, you're breaking an
    invariant in the linker that only used packages are put into the
    import section of the object file.

    Non-technical issues asides, I think this is a bad idea.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nicolas Sebrecht at Mar 15, 2013 at 5:29 pm

    On Fri, Mar 15, 2013 at 06:19:42PM +0100, Daniel Morsing wrote:

    By throwing away imported and not used errors, you're breaking an
    invariant in the linker that only used packages are put into the
    import section of the object file.
    You're right. I miss background on the subject but I guess this is what
    compilers in other languages does, too. After all, this what I ask to
    the machine: keep unused stuff in the binary and warn me about that.

    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russ Cox at Mar 15, 2013 at 8:46 pm
    Please understand that you are suggesting the creation of a separate
    language dialect.

    Emitting the errors is not the compiler's decision: it is a requirement
    spelled out in the language spec. The requirement is in the language spec
    so that all compilers agree. This is an explicit attempt to avoid the
    fragmentation common in C compilers today, where a program that builds on
    one compiler may well not build on another. It is for the same reason that
    the language spec (for Go 1.1) spells out explicitly when a function is
    missing a return statement. We are trying very hard to preserve the
    property that all Go compilers agree on which programs are okay and which
    are not.

    Programs that build with your patched compiler are now no longer guaranteed
    to build with the standard compilers. Code you publish may fail to 'go get'
    for others. This is a very high price to pay to avoid putting 'var _ =
    fmt.Printf' at the top of a file that imports "fmt", or to put '_ = x'
    after a declaration of x that you'd like to toggle between using and not
    using while developing.

    As to the specific errors, please remember that we are trying to build a
    language that scales well with large programs. Part of that is making sure
    that various cleanliness properties are followed by default: not having
    dead imports or dead variables lying around is one of those. Of course we
    understand that new code has different needs than production code. That's
    why we provided a mechanism for suppressing the error *selectively*, in the
    rougher parts of the code, in a way that still keeps the error enabled in
    the rest of the code and that serves as a signal that this part of the code
    is not yet finished and needs to be cleaned up. For more on the general
    design, see http://talks.golang.org/2012/splash.article.

    If you use a particular IDE, perhaps a more productive and less disruptive
    approach would be to make the IDE insert the _ = statements automatically
    in response to compiler errors.

    Thanks.
    Russ

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nicolas Sebrecht at Mar 16, 2013 at 1:21 pm

    On Fri, Mar 15, 2013 at 04:46:50PM -0400, Russ Cox wrote:

    Please understand that you are suggesting the creation of a separate
    language dialect.

    Emitting the errors is not the compiler's decision: it is a requirement
    spelled out in the language spec. The requirement is in the language spec
    so that all compilers agree. This is an explicit attempt to avoid the
    fragmentation common in C compilers today, where a program that builds on
    one compiler may well not build on another. It is for the same reason that
    the language spec (for Go 1.1) spells out explicitly when a function is
    missing a return statement. We are trying very hard to preserve the
    property that all Go compilers agree on which programs are okay and which
    are not.
    As said in my previous mail, I agree with the language spec and the
    purpose of this design.
    Programs that build with your patched compiler are now no longer guaranteed
    to build with the standard compilers.
    Yes, the patch is a starting point to allow hacking sessions. The goal
    is not to change the default policy.


    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jackie Li at Mar 16, 2013 at 3:58 pm
    I'm not sure who's stubborn here.

    I, maybe like almost everybody here, don't want to see Go into
    fragmentation. I sincerely hope you find your tool or hack work for you,
    even after many years.

    Wishes.

    On Sat, Mar 16, 2013 at 2:22 PM, Nicolas Sebrecht wrote:
    On Fri, Mar 15, 2013 at 04:46:50PM -0400, Russ Cox wrote:

    Please understand that you are suggesting the creation of a separate
    language dialect.

    Emitting the errors is not the compiler's decision: it is a requirement
    spelled out in the language spec. The requirement is in the language spec
    so that all compilers agree. This is an explicit attempt to avoid the
    fragmentation common in C compilers today, where a program that builds on
    one compiler may well not build on another. It is for the same reason that
    the language spec (for Go 1.1) spells out explicitly when a function is
    missing a return statement. We are trying very hard to preserve the
    property that all Go compilers agree on which programs are okay and which
    are not.
    As said in my previous mail, I agree with the language spec and the
    purpose of this design.
    Programs that build with your patched compiler are now no longer
    guaranteed
    to build with the standard compilers.
    Yes, the patch is a starting point to allow hacking sessions. The goal
    is not to change the default policy.


    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Jackie

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Elazar Leibovich at Mar 21, 2013 at 2:36 pm

    On Friday, March 15, 2013 10:46:50 PM UTC+2, Russ Cox wrote:
    Please understand that you are suggesting the creation of a separate
    language dialect.

    Emitting the errors is not the compiler's decision: it is a requirement
    spelled out in the language spec. The requirement is in the language spec
    so that all compilers agree. This is an explicit attempt to avoid the
    fragmentation common in C compilers today, where a program that builds on
    one compiler may well not build on another. It is for the same reason that
    the language spec (for Go 1.1) spells out explicitly when a function is
    missing a return statement. We are trying very hard to preserve the
    property that all Go compilers agree on which programs are okay and which
    are not.

    Programs that build with your patched compiler are now no longer
    guaranteed to build with the standard compilers. Code you publish may fail
    to 'go get' for others. This is a very high price to pay to avoid putting
    'var _ = fmt.Printf' at the top of a file that imports "fmt", or to put '_
    = x' after a declaration of x that you'd like to toggle between using and
    not using while developing.
    If you use a particular IDE, perhaps a more productive and less disruptive
    approach would be to make the IDE insert the _ = statements automatically
    in response to compiler errors.
    Correct me if I'm wrong, but if a compiler would compile the package to
    executables, but would refuse to compile and install the package (eg, would
    delete all ".a" files created in the process), the "fragmentation" you
    described wouldn't happen, would it? Everyone would use the "strict"
    compiler to "go get" packages, in their build bots, etc. When one wishes
    use it locally, he can use the run-only compiler to run his broken code,
    but he would not be able to send the build results out of the sandbox.

    If a tree falls in the forest and no one heard it, did it define a
    different Go language?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at Mar 21, 2013 at 2:58 pm
    On Thu, Mar 21, 2013 at 3:36 PM, Elazar Leibovich wrote:

    IMHO, you're doing something wrong. I don't know what, but your
    "problem" doesn't seem to be a problem for many others. Or at least a
    very minor and temporary problem*. IMHO it would be a benefit for you
    to figure out why it is a problem for you while not a problem for many
    others - instead of creating a tool which doesn't help in this.
    Actually it servers the opposite - it petrifies that "something"
    wrong. "Unlearning" it later would be harder.

    As an ad hoc hypothesis of what might be biting you: I had a quick
    peek at some of your code and it is basically okay, I think. The
    _only_ thing I noticed glancing quickly over it is the sometimes non
    idiomatic use of 'else' and thus too deeply nested structures
    happening. Could that be the culprit? However, I don't see the
    connection by myself. Call this a "technical analysis". Probably
    "fundamental analysis" is what is really needed.

    -j

    (*) During initial coding, unused variable errors are a BIG help for
    me, not an annoyance. During later debugging sessions, one can use the
    'if false {' /* h/t mtj /* ) }' trick which _doesn't_ introduce any
    unused variable errors. So where, at which situation the "problem"
    arises for you?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Elazar Leibovich at Mar 21, 2013 at 3:31 pm
    I think I mentioned that in the past, but as you mentioned, during initial
    coding - I'm very happy to get errors with unused variable.

    When I'm getting an unexpected error in an existing project, I find it
    helpful to tuck print statements here and there, or to remove segments of
    code, and see if the problem persist. I don't care about the correctness of
    the overall code, just about locating the problem (e.g. does this code path
    correlate to the problem I'm seeing. A very easy way to test the hypothesis
    is to tuck a print statement there).

    Another use is exploring unknown API. Again, I'm making an hypothesis on
    the API (not everything is documented, some things not at all), trying it
    out, making another hypothesis and testing it again. In during those tests
    I don't care about the quality of the overall code. It is similar to the
    uses of the REPL, or a matlab/maple notebook.

    I don't like the "if false" solution, since I'd rather the "draft" code
    would give me errors after I'm done exploring.

    Am I doing something wrong? Maybe, but I need to understand what it is, and
    I need to find a good alternative (I've heard about the approach of "do not
    try many things, just read the code and think about it". I find this
    approach attractive, but in practice it didn't always work for me. Sounds
    like the difference between math and biology). I'll be happy for any other
    analysis of my potential fundamental mistake if anyone else has an
    observation.

    On Thu, Mar 21, 2013 at 4:51 PM, Jan Mercl wrote:

    On Thu, Mar 21, 2013 at 3:36 PM, Elazar Leibovich wrote:

    IMHO, you're doing something wrong. I don't know what, but your
    "problem" doesn't seem to be a problem for many others. Or at least a
    very minor and temporary problem*. IMHO it would be a benefit for you
    to figure out why it is a problem for you while not a problem for many
    others - instead of creating a tool which doesn't help in this.
    Actually it servers the opposite - it petrifies that "something"
    wrong. "Unlearning" it later would be harder.

    As an ad hoc hypothesis of what might be biting you: I had a quick
    peek at some of your code and it is basically okay, I think. The
    _only_ thing I noticed glancing quickly over it is the sometimes non
    idiomatic use of 'else' and thus too deeply nested structures
    happening. Could that be the culprit? However, I don't see the
    connection by myself. Call this a "technical analysis". Probably
    "fundamental analysis" is what is really needed.

    -j

    (*) During initial coding, unused variable errors are a BIG help for
    me, not an annoyance. During later debugging sessions, one can use the
    'if false {' /* h/t mtj /* ) }' trick which _doesn't_ introduce any
    unused variable errors. So where, at which situation the "problem"
    arises for you?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Sam Harwell at Mar 21, 2013 at 4:33 pm
    The solution you're looking for is a fast, easy to use, full-featured debugger.

    We're working on it for a coming release of GoWorks (it will likely debut in Preview 9). :)

    --
    Sam Harwell
    Owner, Lead Developer
    http://tunnelvisionlabs.com

    From: golang-nuts@googlegroups.com On Behalf Of Elazar Leibovich
    Sent: Thursday, March 21, 2013 10:32 AM
    To: Jan Mercl
    Cc: golang-nuts; Nicolas Sebrecht; Daniel Morsing; Sam Harwell; Volker Dobler
    Subject: Re: [go-nuts] Re: [PATCH] turn compiler errors on unused variables and imports into warnings

    I think I mentioned that in the past, but as you mentioned, during initial coding - I'm very happy to get errors with unused variable.

    When I'm getting an unexpected error in an existing project, I find it helpful to tuck print statements here and there, or to remove segments of code, and see if the problem persist. I don't care about the correctness of the overall code, just about locating the problem (e.g. does this code path correlate to the problem I'm seeing. A very easy way to test the hypothesis is to tuck a print statement there).

    Another use is exploring unknown API. Again, I'm making an hypothesis on the API (not everything is documented, some things not at all), trying it out, making another hypothesis and testing it again. In during those tests I don't care about the quality of the overall code. It is similar to the uses of the REPL, or a matlab/maple notebook.

    I don't like the "if false" solution, since I'd rather the "draft" code would give me errors after I'm done exploring.

    Am I doing something wrong? Maybe, but I need to understand what it is, and I need to find a good alternative (I've heard about the approach of "do not try many things, just read the code and think about it". I find this approach attractive, but in practice it didn't always work for me. Sounds like the difference between math and biology). I'll be happy for any other analysis of my potential fundamental mistake if anyone else has an observation.

    On Thu, Mar 21, 2013 at 4:51 PM, Jan Mercl wrote:
    On Thu, Mar 21, 2013<tel:2013> at 3:36 PM, Elazar Leibovich wrote:

    IMHO, you're doing something wrong. I don't know what, but your
    "problem" doesn't seem to be a problem for many others. Or at least a
    very minor and temporary problem*. IMHO it would be a benefit for you
    to figure out why it is a problem for you while not a problem for many
    others - instead of creating a tool which doesn't help in this.
    Actually it servers the opposite - it petrifies that "something"
    wrong. "Unlearning" it later would be harder.

    As an ad hoc hypothesis of what might be biting you: I had a quick
    peek at some of your code and it is basically okay, I think. The
    _only_ thing I noticed glancing quickly over it is the sometimes non
    idiomatic use of 'else' and thus too deeply nested structures
    happening. Could that be the culprit? However, I don't see the
    connection by myself. Call this a "technical analysis". Probably
    "fundamental analysis" is what is really needed.

    -j

    (*) During initial coding, unused variable errors are a BIG help for
    me, not an annoyance. During later debugging sessions, one can use the
    'if false {' /* h/t mtj /* ) }' trick which _doesn't_ introduce any
    unused variable errors. So where, at which situation the "problem"
    arises for you?

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com .
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Mar 21, 2013 at 8:09 pm

    On Thursday, March 21, 2013 8:36:08 AM UTC-6, Elazar Leibovich wrote:

    Correct me if I'm wrong, but if a compiler would compile the package to
    executables, but would refuse to compile and install the package (eg, would
    delete all ".a" files created in the process), the "fragmentation" you
    described wouldn't happen, would it? Everyone would use the "strict"
    compiler to "go get" packages, in their build bots, etc. When one wishes
    use it locally, he can use the run-only compiler to run his broken code,
    but he would not be able to send the build results out of the sandbox.
    The concept of an "install" is not the job of the compiler -- in this case,
    the compiler doesn't handle that, but the go tool does.

    IMO, compiler options are for configuring the _interpretation_ of required
    runtime behavior when the language specification was ambiguous or
    under-descriptive. C, for example, leaves the behavior of integer overflow
    undefined, and compiler options can configure various intepretations (do
    whatever is most efficient at the cost of reliability/predictability; use
    consistent wraparound behavior; etc). In all these areas, Go specifies the
    precise behavior. The question of allowing unused variables/expressions is
    not a runtime behavior. Moreover, it's a simple matter of adding or
    removing whole lines of formatted code; Go's syntax makes it trivial to
    write tools for this kind of processing, and this kind of processing should
    go in a development tool (such as a wrapper around the compiler), rather
    than the compiler itself; if you write a tool to handle this, I doubt
    you'll get any criticism, while trying to stress that it go in the compiler
    will continue to get criticism even from some of the people who find these
    errors annoying.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dougx at Mar 17, 2013 at 12:19 pm
    Thank you for posting that.

    I spent the last 2 minutes reading this thread going, wtf, if you're that
    convinced it shouldn't be an error, just patch the source.

    I'm glad to see someone here is actually willing to do more than just
    complain about the things that bug them.

    (No, I'm not endorsing using a fragmented version of go, I'm just saying,
    its refreshing to see someone actually pickup the challenge of trying to
    fix something that irritates them, rather than just complain. I wonder if
    anyone will implement generics... :)

    ~
    Doug.
    On Saturday, March 16, 2013 12:55:50 AM UTC+8, Nicolas Sebrecht wrote:
    On Thu, Mar 14, 2013 at 09:35:32PM +0100, Nicolas Sebrecht wrote:
    On Thu, Mar 14, 2013 at 05:55:50PM +0000, Sam Harwell wrote:

    1. Go's compiler is open source and the license permits such
    alteration
    2. If not already done by someone else, I plan personally create
    the fork (perhaps for internal use only) the next time we get a contract
    working with a Go project. Naturally our deliverables would compile without
    warnings, but we are highly productive during rapid prototyping and the Go
    compiler proved extremely cumbersome in practice last time we were working
    with it.
    If such initiative is made public I would be one of the users. Honestly,
    I would even be very happy with only floating patches to apply on my
    own. ;-)
    Here is a starting point. The current patch turns compiler errors for
    unused
    stuff into warnings. It looks to work fine for me. Not widely tested, yet.

    Also, the patch definetly turns errors into warnings. No option is exposed
    to
    the user.

    Now, I'll be happy to hack with go. ,-)

    Applies fine on top of go1.0.3 (changeset 16127:70d1d0a4bcab to be exact).


    diff -r d5666bad617d src/cmd/gc/lex.c
    --- a/src/cmd/gc/lex.c Thu Sep 27 15:36:22 2012 -0700
    +++ b/src/cmd/gc/lex.c Fri Mar 15 18:47:10 2013 +0100
    @@ -2200,7 +2200,7 @@
    // errors if a conflicting
    top-level name is
    // introduced by a different file.
    if(!s->def->used &&
    !nsyntaxerrors)
    - yyerrorl(s->def->lineno,
    "imported and not used: \"%Z\"", s->def->pkg->path);
    + warnl(s->def->lineno,
    "imported and not used: \"%Z\"", s->def->pkg->path);
    s->def = N;
    continue;
    }
    @@ -2208,7 +2208,7 @@
    // throw away top-level name left
    over
    // from previous import . "x"
    if(s->def->pack != N &&
    !s->def->pack->used && !nsyntaxerrors) {
    -
    yyerrorl(s->def->pack->lineno, "imported and not used: \"%Z\"",
    s->def->pack->pkg->path);
    +
    warnl(s->def->pack->lineno, "imported and not used: \"%Z\"",
    s->def->pack->pkg->path);
    s->def->pack->used = 1;
    }
    s->def = N;
    diff -r d5666bad617d src/cmd/gc/subr.c
    --- a/src/cmd/gc/subr.c Thu Sep 27 15:36:22 2012 -0700
    +++ b/src/cmd/gc/subr.c Fri Mar 15 18:47:10 2013 +0100
    @@ -400,7 +400,7 @@
    }
    if(n == 0) {
    // can't possibly be used - there were no symbols
    - yyerrorl(pack->lineno, "imported and not used: \"%Z\"",
    opkg->path);
    + warnl(pack->lineno, "imported and not used: \"%Z\"",
    opkg->path);
    }
    }

    diff -r d5666bad617d src/cmd/gc/walk.c
    --- a/src/cmd/gc/walk.c Thu Sep 27 15:36:22 2012 -0700
    +++ b/src/cmd/gc/walk.c Fri Mar 15 18:47:10 2013 +0100
    @@ -94,11 +94,11 @@
    if(l->n->defn->left->used)
    continue;
    lineno = l->n->defn->left->lineno;
    - yyerror("%S declared and not used", l->n->sym);
    + warn("%S declared and not used", l->n->sym);
    l->n->defn->left->used = 1; // suppress repeats
    } else {
    lineno = l->n->lineno;
    - yyerror("%S declared and not used", l->n->sym);
    + warn("%S declared and not used", l->n->sym);
    }
    }

    --
    Nicolas Sebrecht
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nicolas Sebrecht at Mar 14, 2013 at 7:27 pm

    On Thu, Mar 14, 2013 at 10:37:36AM -0700, Volker Dobler wrote:
    Am Donnerstag, 14. März 2013 18:20:54 UTC+1 schrieb Nicolas Sebrecht:
    On Wed, Mar 13, 2013 at 04:51:04PM -0700, Carlos Castillo wrote:

    Never use it outside a local and experimental use case.
    Printing this line and hoping such debug stuff won't make it to prod
    because "it was clearly stated" is what does not work in reality.

    Let's face reality. Get used to strict compilers.
    The reality is not that beauty. It is only a question of time before you
    hit garbage underscored and unused stuff in code compiled for
    production.
    (It's worth googeling how they code for the mars rover at JET:
    Not _any_ warning from _any_ compiler or _any_ code
    analysis tool is allowed. Period. And I think they know why.)
    Yes. I'm in favor of even stronger policy for the normal go build tool.
    I think that code not passing gofmt cleanly should not be compiled and
    stop with errors.

    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Carlos Castillo at Mar 14, 2013 at 9:11 pm
    Any text editor's find feature can find uses of underscores where you are
    "getting around" the strictness of the compiler. Tools can be built to
    detect this code pattern as well. The point is, it's very obvious that you
    are doing something hackish, when you use an underscore, and very easy to
    find. This makes it much easier to fix, clean up and optimize the code,
    even when you aren't the original author.
    On Thursday, March 14, 2013 12:27:44 PM UTC-7, Nicolas Sebrecht wrote:
    On Thu, Mar 14, 2013 at 10:37:36AM -0700, Volker Dobler wrote:
    Am Donnerstag, 14. M�rz 2013 18:20:54 UTC+1 schrieb Nicolas Sebrecht:
    On Wed, Mar 13, 2013 at 04:51:04PM -0700, Carlos Castillo wrote:

    Never use it outside a local and experimental use case.
    Printing this line and hoping such debug stuff won't make it to prod
    because "it was clearly stated" is what does not work in reality.

    Let's face reality. Get used to strict compilers.
    The reality is not that beauty. It is only a question of time before you
    hit garbage underscored and unused stuff in code compiled for
    production.
    (It's worth googeling how they code for the mars rover at JET:
    Not _any_ warning from _any_ compiler or _any_ code
    analysis tool is allowed. Period. And I think they know why.)
    Yes. I'm in favor of even stronger policy for the normal go build tool.
    I think that code not passing gofmt cleanly should not be compiled and
    stop with errors.

    --
    Nicolas Sebrecht
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nicolas Sebrecht at Mar 15, 2013 at 4:19 pm

    On Thu, Mar 14, 2013 at 02:11:22PM -0700, Carlos Castillo wrote:

    Any text editor's find feature can find uses of underscores where you are
    "getting around" the strictness of the compiler.
    It's still boring. And it's worse with expected underscores.
    Tools can be built to
    detect this code pattern as well. The point is, it's very obvious that you
    are doing something hackish, when you use an underscore, and very easy to
    find. This makes it much easier to fix, clean up and optimize the code,
    even when you aren't the original author.
    The tool to detect unused stuff, clean up and optimize the code already
    exists. It's called a compiler. ,-p
    This is the right tool to handle that.

    --
    Nicolas Sebrecht

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Carlos Castillo at Mar 15, 2013 at 6:07 pm
    You are expecting the compiler to turn poor code into good code. This
    requires many man hours of programmer effort (programmers who are probably
    not you BTW), to make a compiler that runs slower, and may still not
    produce the optimal result(certainly not in all cases). All to avoid you
    having to (in some situations) type 2 characters ("_=") to tell the
    compiler to ignore it's strict adherence to the language spec, or to delete
    a line that has no effect.

    You should focus on writing better code, its a better use of everyone's
    time.

    On Fri, Mar 15, 2013 at 10:19 AM, Nicolas Sebrecht wrote:
    On Thu, Mar 14, 2013 at 02:11:22PM -0700, Carlos Castillo wrote:

    Any text editor's find feature can find uses of underscores where you are
    "getting around" the strictness of the compiler.
    It's still boring. And it's worse with expected underscores.
    Tools can be built to
    detect this code pattern as well. The point is, it's very obvious that you
    are doing something hackish, when you use an underscore, and very easy to
    find. This makes it much easier to fix, clean up and optimize the code,
    even when you aren't the original author.
    The tool to detect unused stuff, clean up and optimize the code already
    exists. It's called a compiler. ,-p
    This is the right tool to handle that.

    --
    Nicolas Sebrecht


    --
    Carlos Castillo

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

People

Translate

site design / logo © 2021 Grokbase