spec: field tags have to be identical when casting

[lukescott]

Run this:

package main

type Message struct {
    Id   int    `db:"id"`
    Text string `db:"text"`
}

type Message2 struct {
    Id   int    `json:"id" xml:"id,attr"`
    Text string `json:"text"`
}

func main() {
    msg := Message{1, "Hello"}
    msg2 := Message2(msg)
    _ = msg2
}

What is the expected output?

[no output]

What do you see instead?

cannot convert msg (type Message) to type Message2

Which compiler are you using (5g, 6g, 8g, gccgo)?

Which version are you using?  (run 'go version')

go version devel +d744da8c8cbf Wed Sep 25 16:18:33 2013 -0400 darwin/amd64

Please provide any additional information below.

I'm trying to decouple my database layer from my service layer into separate packages.
Tags in one package are only relevant to that package. What I'd like to do is re-define
the struct in my service layer and cast it from the database layer. The fields inside
the struct are otherwise exactly the same, besides the tags.

Unfortunately it won't cast unless the tags are also exactly the same. The only solution
I have at this point is put the structs in a "common" package that both the
database and service layers share. But then I'm mixing tags...

[minux]

Comment 1:

this is working as intended, or rather, working according to the spec.
http://golang.org/ref/spec#Type_identity
are you suggesting a language change?

[ianlancetaylor]

Comment 2:

I think we could consider a language change here.  The current definition is
conservative.  We could loosen it without causing any valid programs to become invalid. 
Considering the way that tag use has evolved, it seems to me that there is a valid
argument for loosening it.

Labels changed: added languagechange.

[rsc]

Comment 3:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 4:

Labels changed: added repo-main.

[robpike]

Comment 5:

This is worth discussion. I am content with what's defined now but there are situations
where the proposed change could be beneficial. It would be a backwards-compatible change.
I am voting neither for nor against at this point.

Owner changed to @griesemer.

Status changed to Accepted.