Thus can create some subtle errors. Suppose T3’s field was named bar. And the above example will print 1 for t1.foo. Now change T3 field to foo. And t1.foo will be 2.
> On Oct 25, 2017, at 6:44 AM, Ian Lance Taylor <i...@golang.org> wrote: > > I'll speculate that perhaps you would prefer a compilation error due > to an ambiguous field. Not doing that was an explicit decision. > Consider a struct in package P1 that embeds two structs, one from > package P2 and one from P3. Suppose the struct in P3 embeds another > struct from P4. Suppose that all four packages are in different > github repos maintained by different people; recall that one of the > explicit goals of the Go language is to support programming at scale. > With this organization, package P1 can refer directly to fields > defined in P2 and P3. We want it to be possible for P4 to add a > field, a field that might happen to duplicate a field in P2--in this > example, P2 and P4 might not even know about each other at all--and we > want that to happen without breaking P1. Hope that makes sense. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
