"cannot refer to unexported field" (which I don't see as exported)

1,320 views
Skip to first unread message

distributed

unread,
Nov 23, 2013, 12:09:33 PM11/23/13
to golan...@googlegroups.com
I'm facing a strange problem with unexported and embedded fields. I have two packages, shown below.

In file exp/exp.go

package exp

type Exported struct {
        Field int
}

type shell struct {
        Exported
        error
}

func GetLeStuff() (Exported, error) {
        val := shell{Exported{42}, nil}
        return val.Exported, val.error
}

And then in imp/imp.go

package main

import (
        "fmt"
)

func main() {
        i, err := exp.GetLeStuff()
        fmt.Println(i, err)
}

(The import path are specified for the Github repository linked below)

Compiling fails with the following error messages:

# imp
imp/imp.go:5: unknown exp.shell field 'exp.error' in struct literal
imp/imp.go:5: exp.val·3.error undefined (cannot refer to unexported field or method exp.error)
imp/imp.go:9: tempname called with nil type

I don't understand that. error is a built in type, the type shell is unexported and I don't try to expose it to the user. The fields of shell are picked out and exposed to the user individually, leaving us with values of types Exported and error.

Is this expected to fail? If so, where is the mistake in my reasoning? If not, is this a bug? (Inlining? :) )

If you want to get the code easily, try

Brad Fitzpatrick

unread,
Nov 23, 2013, 12:19:13 PM11/23/13
to distributed, golang-nuts
Which version of Go?  Try Go1.2rc5.  This sounds familiar... I think it was fixed.



--
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.
For more options, visit https://groups.google.com/groups/opt_out.

distributed

unread,
Nov 23, 2013, 12:45:15 PM11/23/13
to golan...@googlegroups.com, distributed
Sorry for not mentioning that. I believed to be on tip, however that doesn't seem to be the case ;)

$ go version
go version go1.1.2 darwin/amd64

I don't see the problem on go1.2rc5 or tip. Thanks! :)


Cheers,
Michael

P.S. The Go team and community are very responsive and helpful, all while being free. Many paid support contracts offer less than that. Awesome :)
Reply all
Reply to author
Forward
0 new messages