Be Careful with Go Struct Embedding

   type Foo struct { 
       sync.Mutex
       whatever string
   }
   var foo Foo
   foo.Lock()
   foo.whatever = 42
   foo.Unlock()

https://go.dev/play/p/r04tPta1xZo

So the whole article is basically about using the language in a way you normally would ever do.

https://go.dev/doc/effective_go#embedding

> Embedding types introduces the problem of name conflicts but the rules to resolve them are simple. First, a field or method X hides any other item X in a more deeply nested part of the type. If log.Logger contained a field or method called Command, the Command field of Job would dominate it.

> Second, if the same name appears at the same nesting level, it is usually an error; it would be erroneous to embed log.Logger if the Job struct contained another field or method called Logger. However, if the duplicate name is never mentioned in the program outside the type definition, it is OK. This qualification provides some protection against changes made to types embedded from outside; there is no problem if a field is added that conflicts with another field in another subtype if neither field is ever used.

   type Foo struct {
      somepackage.Bar
      URL string
   }

Even more, imagine in the future authors of `somepackage` decided to add URL to their struct and it suddendly started to break your code from being compiled.

Example in the OP article is a corner case where this behavior is creating ambiguity, indeed. Yet, it's documented and intentional.

[1] http://doc.cat-v.org/plan_9/4th_edition/papers/comp, look for “anonymous structure or union” and note that a (different) part of that extension has since been standardized.

https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Unnamed-Fields....

While it may seem questionable for fields; it applies to methods too and is potentially more useful as a way to override them when doing struct embedding but wanting to preserve an interface.

Read the article. It won't.

At best you can perhaps find a linter that'll report it?

> However, I wouldn't use this approach when writing my own code.

You might use it by accident.

golangci-lint run --enable-all --max-issues-per-linter=0 --max-same-issues=0

But yes, for anything more complicated I have generally regretted trying to embed structs. I think requiring "unsafe" is a bit too strong, but I think the syntax should've been uglier / more in-your-face to discourage its use.

(Fellow 10+ years Go user.)

As long as these two aren't there, embedding structs is literally identical to dispatching methods, and can't be used for anything else due to lack of state management through it. You have to manage the states externally anyways from a memory ownership perspective.

  var x string
  x = "abc.com"
  x = "xyz.com"
  fmt.Println(x)

The normal intuition would be that the latter operations or (re)definitions override the preceding ones.

I was very surprised that either example compiled, though.

This problem has happened to me once.

Would you care to make a list of all the problems your favorite language has served up to you at a rate of once in ten years, so I can also write a post making your language sound horrible as a result?

I bet the reasons were very mundane: initial project scope, deadlines, performance review cycle. "This simplest thing that could possibly work", etc.

Even given that it compiles, I wouldn’t exclude it being a runtime error.

But the big problem isn’t that it behaves as advertised, it’s that it is way too easy to write opts.URL where you mean opts.Bar.URL. Auto-complete will happily compete the wrong thing for you.

I feel like sometimes people just want to complain.

doesn't this just shove the problem down a level?

e.g. if somepackage.Bar suddenly gets a member with same name as one of your URL members?

The article talks about "opts.URL" in its example being accepted by the compiler, which accesses "opts.FooService.URL" without using the embedded type's name.