<p>Hi. As far as I understood, go allows structs that embed another struct to call the methods from the embedded struct as if it were a derived class, like this:</p>
<pre><code>type embedded struct {
name string
value int
}
func (p *embedded) double() int {
return p.value * 2
}
type embedding struct {
embedded
ext bool
}
func main() {
var p = &embedded{"hello", 1}
var d = &embedding{embedded{"world", 2}, true}
println(p.double())
println(d.double(), d.ext)
}
</code></pre>
<p>So the method <code>double()</code> can be called from both <code>p</code> and <code>d</code>. So far, so good. What I don't understand is why it doesn't work when an embedding struct is the argument to a function that expects the embedded struct, like this:</p>
<pre><code>func printName(p *embedded) {
println(p.name)
}
</code></pre>
<p>That function cannot be called from main with <code>printName(d)</code> but requires <code>printName(&d.embedded)</code>. Can't the compiler infer that? Am I doing something wrong?</p>
<hr/>**评论：**<br/><br/>ChristophBerger: <pre><p>Struct embedding provides a shortcut for accessing fields and methods of the embedded struct. <code>func printName</code>, on the other hand, expects an <code>embedded</code> but <code>printName(d)</code> passes an <code>embedding</code> instead. This is a classic type mismatch. There is no field or method access happening in <code>printName(d)</code>, so the shortcut rules do not apply. </p>
<p>This should work:</p>
<pre><code>func printName(name string) {
println(name)
}
printName(p.name)
printName(d.name) // field access shortcut
</code></pre>
<p>Edit: added the p.name line</p></pre>anotherdonald: <pre><p>I know that works, but it seems to me the inference embedding->embedded could be the same for both the method and the function, since essentially the method argument is nothing but a parameter.</p></pre>TheMerovius: <pre><p>Embedding isn't subtyping and that's intentional. Your <code>embedding</code> doesn't <em>become</em> an <code>embedded</code>, it <em>embeds</em> it. Yes, of course go <em>could</em> make embedding be subtyping, but it discourages what some of the go team call "programming types", which is what happens naturally in a world where subtyping exist (see java, for an example, where "java coding" in general means "building elaborated type hierarchies that make it impossible to understand what is actually going on"). </p></pre>anotherdonald: <pre><p>Thanks.</p>
<p>But as there is no overloading, there can only be one function with that specific name (printName in my case), which renders the potential confusion rather limited, IMO. And the same argument would also hold against struct methods: I could just as well write <code>d.embedded.double()</code>.</p>
<p>But if you say it's intentional, I'll have to live with it.</p></pre>TheMerovius: <pre><p>I didn't talk about "confusion".
And if Methods weren't promoted, it would limit the use of embedding for interface implementation. But note also, that the method will still be called on an <code>embedded</code>, not an <code>embedding</code>, so it's not really like an <code>embedding</code> would become an <code>embedded</code> in that sense.</p></pre>anotherdonald: <pre><blockquote>
<p>I didn't talk about "confusion".</p>
</blockquote>
<p>I took your statement "impossible to understand what is actually going on" to mean that in Java it can be hard to know what's happening by just reading the code since there can so many candidates for a function or method call, and I can't see that happen with automatic de-embedding.</p>
<blockquote>
<p>But note also, that the method will still be called on an embedded, not an embedding, so it's not really like an embedding would become an embedded in that sense.</p>
</blockquote>
<p>Sure, I wasn't expecting anything else. I was just hoping the compiler would automatically insert .embedded for me.</p></pre>joncalhoun: <pre><p>If you really just care about "does it have access to x" then you probably want to use interfaces, but this means you need to write a method to access name. eg: <a href="https://play.golang.org/p/TmigbUQKw5" rel="nofollow">https://play.golang.org/p/TmigbUQKw5</a></p></pre>knotdjb: <pre><p>You want to pass <code>&d.embedded</code> <a href="https://play.golang.org/p/ke_T1SA0j7" rel="nofollow">like so</a>.</p>
<blockquote>
<p>Can't the compiler infer that?</p>
</blockquote>
<p>I assume it probably could but this violates the notion of strong typing which is a feature of Go.</p></pre>Tikiatua: <pre><p>You should create an interface that defines any methods you want to call on the struct passed to the print function.</p>
<p>You can then pass your struct with the embedded struct into the function.</p>
<p>The most basic imterface would be interface{}.</p></pre>NeverUse-YouPromised: <pre><p>structs can embed interfaces too. So you could do something like</p>
<pre><code>type NameValuer interface {
Name() string
Value() int
}
func (p *embedded) Name() string {
return name
}
func (p *embedded) Value() int {
return value
}
type embedding struct {
NameValuer
ext bool
}
func printName(p NameValuer) {
println(p.Name())
}
</code></pre>
<p>And now <code>printname(d)</code> works. However, I don't recommend doing so as it's probably not idiomatic Go and confuses the roles of structs and interfaces. The typical use of interface embedding is to override methods of the parent; for example, <code>sort.Reverse</code> embeds another <code>sort.Interface</code> and overrides its <code>Less</code> method to compare the operands in reverse.</p></pre>anotherdonald: <pre><p>Yes, thanks. I know about interfaces, but it seemed so obvious to me that if both types can be used in the context of one function call, that they can also be used in the context of another. I've given up on this approach for the moment, and made a big "union" struct with a field that specifies the type. Ugly, but easy on the calling functions.</p></pre>
