Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: support "var identifier = _" to mute an identifier in certain scope. #17389

Closed
go101 opened this issue Oct 9, 2016 · 17 comments
Closed

Comments

@go101
Copy link

go101 commented Oct 9, 2016

This is helpful to avoid using some identifiers which should be used in some scopes carelessly.

Example:

package main

func main(){
    var n = 123,
    // use n

    {
        // use n

        var n = _
        // now n disppears
    }

    // here, n is still alive
    // use n
}
@go101 go101 changed the title proposal: support "identifier = _" to mute an identifier in certain scope. proposal: support "var identifier = _" to mute an identifier in certain scope. Oct 9, 2016
@stemar94
Copy link

stemar94 commented Oct 9, 2016

you can simply shadow your variables

var n = 123
{
    // use n

    n := n // or var n = n
    // now the real n can no longer be accessed
}
// here, n is still alive

https://play.golang.org/p/KOUBa5TVIv

@go101
Copy link
Author

go101 commented Oct 9, 2016

you can simply shadow your variables

it is not totally the same

@stemar94
Copy link

stemar94 commented Oct 9, 2016

How about

const n = 1i // complex number

or

n_ := n
\\ no longer allowed to use/change n
if n != n_ {
    panic("n was modified")
}

I still don't get your use case.

@stemar94
Copy link

stemar94 commented Oct 9, 2016

Maybe you want to solve it like this:
https://play.golang.org/p/r1cG8oPS8I

@cznic
Copy link
Contributor

cznic commented Oct 9, 2016

Put this into any of your *_test.go files

func use(...interface{}) {}

Silent the unused variable(s) error anywhere by writing

use(n, o, p)

Bonus: The program does not build when not testing.

@go101
Copy link
Author

go101 commented Oct 9, 2016

a more detailed example:

package main

func main(){
    var n = 123
    n++ // use n

    {
        n++ // use n

        var n = _ // this one will change spec few
        // now n disppears

        n++ // compiling error: n is undefined
    }

    // here, n is still alive
    n++ 

    var n = _ // // this one will change spec much
    // now n disppears

    n++ // compiling error: n is undefined

}

It is like the "unset" in some languages.

@mattn
Copy link
Member

mattn commented Oct 9, 2016

use unnamed vars

var n int
_ = n
var n int; _ = n

@stemar94
Copy link

stemar94 commented Oct 9, 2016

I already got what you want to accomplish, but I don't get what it is good for.

@go101
Copy link
Author

go101 commented Oct 9, 2016

I already got what you want to accomplish, but I don't get what it is good for.

just let compiler report errors, just like the two error lines in my example. :)

@go101
Copy link
Author

go101 commented Oct 9, 2016

@mattn,

use unnamed vars

This is not my intention.

@go101
Copy link
Author

go101 commented Oct 9, 2016

@cznic, I don't get your code.

@stemar94
Copy link

stemar94 commented Oct 9, 2016

@cznic, I don't get your code.

It's also only for using unused vars, so not what you want.

@bradfitz
Copy link
Contributor

bradfitz commented Oct 9, 2016

Sorry, previous discussions of overloading _ to mean new things (such as the zero value when _ is used on the RHS) have been rejected. This is similarly not an acceptable language change.

@go101
Copy link
Author

go101 commented Oct 10, 2016

@bradfitz, I think this one is more reasonable.

The underscore "_" is used in many cases now, but it is unnamed.
I think "deaf identifier" is a good name.

var _ = v // deaf variable can't hear anything

var v = _ // v becomes deaf too.

@go101
Copy link
Author

go101 commented Oct 10, 2016

@stemar94,

I already got what you want to accomplish, but I don't get what it is good for.

here is a useful case in reality:

func DoTrasaction(db *sql.DB, sqlStr string) error {
    tx, err := db.Begin()
    if err != nil {
        return err
    }

    var db = _
    // if db can be unset, then we can safely avoid misusing tx as db in following lines        

    // many callings of code
    // ...

    // we should call this
    tx.Exec(sqlStr)
    // but not this
    db.Exec(sqlStr) // if db is not unset, this line is ok
                    // for sql.DB and sql.Tx both has a same Exec method


    // ...

    err = tx.Commit()
    if err != nil {
        return err
    }

    return nil
}

@bradfitz
Copy link
Contributor

You could do: db = nil. Or break the function up into smaller ones with more limited scopes.

@go101
Copy link
Author

go101 commented Oct 10, 2016

ye, there are some ways to avoid this problem, but the unset solution is cooler, ;)

@golang golang locked and limited conversation to collaborators Oct 10, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants