thanks a lot for your answer! However, I’m not convinced, that this inconsistent behaviour is a feature. Because you can intentionally achieve the same effect by making the struct “public” by uppercasing the first letter …
type MyStruct struct {
number int // still unexported
Text string // exported
}
… but with the difference, that in this case, following code is possible and valid:
import (
"fmt"
"myProjekt/loadme"
)
func main() {
var b loadme.MyStruct
b = loadme.ReturnMyStructType()
fmt.Println(b)
}
while
import (
"fmt"
"myProjekt/loadme"
)
func main() {
var b loadme.myStruct
b = loadme.ReturnMyStructType()
fmt.Println(b)
}
Exporting is all about whether you can directly access the identifiers from another package or not. It’s all about the identifiers. It’s not about preventing the usage of those indirectly (like printing an unexported struct etc), because your exported function returns it (because your function has an access to those identifiers).
This is valid because you’re not accessing to any unexported identifiers:
// Here Go infers the type of the `b` variable as `loadme.myStruct`,
// and loads it into the `b` variable.
//
// But you can't "access" myStruct by its "name" (its identifier: myStruct)
b := loadme.ReturnMyStructType()
This is invalid because you’re trying to access to an unexported identifier: myStruct: