go Away()


  • Impossible Mission - B

    Ugh. I just discovered that in Go, "variable is declared but never used" is a compile-time error. Not a warning like it should be, like it is in more sane languages; an error. Which makes incremental development that much more difficult; if you want to evaluate something to a variable, look at its value in the debugger, and then write some more based on what you find, you need to find some way to work around that.

    @ben_lubar or anyone else who works in Go, is there any way to disable that ridiculous error and tell it to go Away()???



  • @masonwheeler Can't you just do a var_dump (or whatever is the equivalent in Go) on it ?
    Would make you see what it contains and make the "never used" error go away at the same time.



  • @masonwheeler at my last workplace, we've had -Werror enabled. When faced with the same problem, we just cast the variable to void. I bet there's some similar no-op thingy in Go.



  • @masonwheeler

    var notSureImGonnaUse;
    notSureImGonnaUse = notSureImGonnaUse;
    

    Will that get rid of the warning? You could put it on one line, and it's harmless if you forget to remove the equals because you're just setting it to itself.



  • If you don't want to use a variable, do this:

    _ = variableName
    


  • @blakeyrat said in go Away():

    @masonwheeler

    var notSureImGonnaUse;
    notSureImGonnaUse = notSureImGonnaUse;
    

    Will that get rid of the warning? You could put it on one line, and it's harmless if you forget to remove the equals because you're just setting it to itself.

    You can do that, but it's recommended that you use _ as the destination for "I don't care about this value" assignments, since x = x looks like a bug in your code.



  • @ben_lubar Ah, I see @masonwheeler's snare has attracted both an M. blakei and a B. conlang (and, I suppose, a G. lambda as well). Good work.



  • @masonwheeler said in go Away():

    Not a warning like it should be

    By the way, they have this in the FAQ: https://golang.org/doc/faq#unused_variables_and_imports



  • @masonwheeler said in go Away():

    is a compile-time error. Not a warning like it should be

    -Werror is always mandatory, so I don't see how this distinction matters.



  • @kian said in go Away():

    @masonwheeler said in go Away():

    is a compile-time error. Not a warning like it should be

    -Werror is always mandatory, so I don't see how this distinction matters.

    -Werror is mandatory for my own code, but not for code written by other people that I just want to goddamn compile goddamnit.



  • @kian said in go Away():

    -Werror is always mandatory, so I don't see how this distinction matters.

    Not during local hacking about it isn't.



  • And this is one of the reasons why I intend to tie the Thelema compiler code generation and warning/error messages to the staging status of the VCS branch being compiled.

    For example, when compiling code that is set to 'development' or 'development-experimental', it would do only the minimum error checking, and generate code in a way that focuses on a fast compile and easy debugging. By default, it would add more tests, and more complex and time-consuming analyses, as the particular update proceeds through to Unit Testing, Integration Testing, Effectiveness Testing (alpha testing), Acceptance Testing (beta testing), Release Candidate, and finally Release.

    It would also be set up to allow specific configuration checklists for each stage, though no stage would be permitted to have less stringent error reporting than the previous stage.

    I suspect it won't work as well as I would like, but AFAICT no one has done it before so it is probably something worth trying out.

    Of course, all of this is predicated on me actually developing the Thelema compiler, something that is, not to put too fine a point on it, probably never going to happen.


  • area_can

    @ben_lubar seems like a pain in the ass to do that for every variable and then undo it when you're done testing whatever change you're working on


  • Impossible Mission - B

    @ben_lubar said in go Away():

    @masonwheeler said in go Away():

    Not a warning like it should be

    By the way, they have this in the FAQ: https://golang.org/doc/faq#unused_variables_and_imports

    Wow. There is so much fail in that FAQ entry it's not even funny. :(


  • Discourse touched me in a no-no place

    @scholrlea said in go Away():

    Release Candidate, and finally Release

    You really want these to be the same, build-options-wise. Probably also for Acceptance Testing too. Otherwise the differences in compilation configuration can cause changes that are problems in themselves.



  • @dkf OK, that's actually a very good point. Thank you.



  • @ben_lubar said in go Away():

    If you don't want to use a variable, do this:

    _ = variableName
    

    (I just googled "go implement an interface", which in retrospect sounds like I'm sending them off somewhere)

    https://play.golang.org/p/zyluP2qBqD , namely:

    package main
    
    import (
    	"fmt"
    )
    
    type Intheface interface {
    	TestIt(arg1 string, arg2 string) string
    }
    
    type Test1 struct {
    }
    
    func (self Test1 ) TestIt(args_dont_need_to_have_the_same_name_as_in_the_interface_thats_a_relief string, arg4 string) string {
    	return "Test1 passed"
    }
    
    type Test2 struct {
    }
    
    func (this Test2) TestIt(_ string, _ string) string {
    	return "Test2 passed"
    }
    
    func main() {
    	tests := []Intheface{Test1 {}, Test2{}}
    	for _, test:= range tests{
    		fmt.Println(test.TestIt("val1", "val2"))
    	}
    }
    

    (8-char wide tabs, seriously?)

    Prints:

    Test1 passed
    Test2 passed
    

    It doesn't complain about unused function arguments. Hypocrite.

    On a secondary note, it accepts _ as the name of more than one argument, which is what I set out to test originally.



  • @zecc why WORD are WORD you WORD repeating WORD the WORD same WORD type WORD after WORD each WORD argument WORD?


  • Impossible Mission - B

    @ben_lubar Perhaps because it's easier to read and understand. You can read a declaration like that left-to-right and understand it all in a single pass with no backtracking. This is not the case when you say (arg1, arg2, arg3, arg4 myType).


    Filed under: Verbosity: not always a bad thing



  • @masonwheeler said in go Away():

    Perhaps because it's easier to read and understand.

    This. Totally this. It's not because I don't know Go's syntax and was basing my code on an example or anything.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.