proposal: Go 2: NoCopy: official support in compiler (not just vet linter)

[ldemailly]

NoCopy official support in compiler (not just vet linter)

This is essentially a repeat of #8005 which got lost through FrozenDueToAge bot

(go versions not relevant - still an issue in go 1.9 and 1.10rc)

What did you do?

I wrote code that has a channel in a struct and got copied accidentally and then closed twice resulting in panic

What did you expect to see?

A way to detect accidental copies for objects that contain resources that need to stay unique
(or alternatively not getting panic when closing a channel more than once, but that's a different can of worm)

What did you see instead?

panic and time spent debugging until we found the trick

type noCopy struct{}
func (*noCopy) Lock() {}

type MyStruct struct {
  noCopy noCopy
  // ...

in #8005 (comment) (thanks for that!)

I believe every go project shouldn't rediscover and reimplement this and more importantly, one would want to get the detection at compile time instead of relying on a linter

while I'm here can I push my luck and ask for const ;-)

[bradfitz]

Why don't I just reopen #8005 instead, which has much more context? Then we don't split the conversation.

[bradfitz]

Oh, nevermind. #8005 was closed intentionally. I thought the vet fix had closed it via a "Fixes #nnn" line.

What's different now? Why should this stay open if #8005 was already closed?

[ldemailly]

I would love #8005 to be reopened as far as I can tell there isn't a documented "NoCopy" (or comment tag) that exist and that the go compiler detects only the above workaround and the vet trick ?

[ianlancetaylor]

As of 1.10 we run go vet for each use of go test, so it's not obvious to me that anything else is needed.

[ldemailly]

Good to know, thanks ! so we just need noCopy -> NoCopy
(and hopefully people would have tests to go test ;-) )

[bcmills]

Moving this check into the compiler would address a fairly important real-world use-case I have, for ensuring that Go wrappers of C++ classes are not copied in Go.

Building a project that mixes Go and C++ code from source in the same binary requires the use of a build tool other than just the go tool, which complicates any safety assumption that relies on that tool. (Specifically, go vet requires access to internal type information for the other packages, which isn't always available when using other build tools.)

[bcmills]

(CC @alandonovan)

[josharian]

Naive question: could cgo do that work?