How Go detects struct copies with sync.noCopy
1 points by rrm
1 points by rrm
It's clever I guess, but I think reliance on this kind of Rube-Goldberg contraption to trick your tooling into safety validation is an anti-pattern. This is something the compiler should be doing.
I think it would feel less gross if this were instead an annotation in a comment that the linter could read. It's not clear to me why they wanted an actual field.
It's not clear to me why they wanted an actual field.
The langage has no proper annotations because “that’s too complicated” / “that’s unnecessary”, and the pragma comments would have required exporting comments (as the code being checked is the user code, which may be a different package).
Furthermore the checker was actually created first, for mutex, by looking for the relevant method(s eventually). When discussions about formalising something came up, that stalled due to the above, which led to the “standardisation” of the structural check, and a helper struct for the stdlib to make more sync types uncopyable.
There's a slight similarity with C++, where adding methods to a class means it's no longer POD and doesn't get an automatic copy constructor, so there's actually sometimes a need for methods that do nothing at all for the specific purpose of preventing copying.
Go doesn't even have classes, but adding the Lock and Unlock functions to the interface makes it no longer copyable. This makes a bit more sense if you're coming from a C++ direction where you add a method to a class to make it uncopyable.
Is there any reason behind why so many things in go take the form of these horrible spooky action at a distance, (convention over configuration)-esque mechanisms?
If these features are needed why not just add them to the language as full-blooded features?