How Go detects struct copies with sync.noCopy
1–10 of 82 posts
Re: How Go detects struct copies with sync.noCopy
#2> noCopy is a special marker for types that must not be copied after their first use.
if it looks like a hack, walks like a hack, and quacks like a hack...
Re: How Go detects struct copies with sync.noCopy
#3> noCopy is a special marker for types that must not be copied after their first use. if it looks like a hack, walks like a hack, and quacks like a hack...
It's not really a hack. It's a hint to a static analyser, that's all.
Re: How Go detects struct copies with sync.noCopy
#4> noCopy is a special marker for types that must not be copied after their first use. if it looks like a hack, walks like a hack, and quacks like a hack...
It's not really a hack. It's a hint to a static analyser, that's all.
Most languages would encode such behavior in a trait or a protocol instead of a zero-length struct field. It's type information and ought to be encoded in the type. From that perspective, I think it is a hack.
Re: How Go detects struct copies with sync.noCopy
#5> noCopy is a special marker for types that must not be copied after their first use. if it looks like a hack, walks like a hack, and quacks like a hack...
Every language can't be rust.
Re: How Go detects struct copies with sync.noCopy
#6This feels like it should ideally be something public in the structs package so anyone can leverage it, not just a specially blessed internal thing for the sync package.
Re: How Go detects struct copies with sync.noCopy
#7Earlier quoted context omitted.
It's not really a hack. It's a hint to a static analyser, that's all.
Most languages would encode such behavior in a trait or a protocol instead of a zero-length struct field. It's type information and ought to be encoded in the type. From that perspective, I think it is a hack.
This feels like a style complaint and not one about substance. An inaccessible (because it's named _) zero-length struct field is just another kind of metadata. It also doesn't require you to pollute the method set, which would be a bigger issue.
The real hack to me is that anything which simply has Lock() and Unlock() methods is considered uncopyable.
Re: How Go detects struct copies with sync.noCopy
#8> noCopy is a special marker for types that must not be copied after their first use. if it looks like a hack, walks like a hack, and quacks like a hack...
It's not really a hack. It's a hint to a static analyser, that's all.
Nah... I like Go, but this is a hack. Wiktionary --not the ultimate authority, I know, but still-- defines to hack as: To make a quick code change to patch a computer program, often one that, while being effective, is inelegant or makes the program harder to maintain.
I could accept having an anonymous embedding as a kind of syntax directive. So many languages have had directives bolted on later, so that wouldn't be a deal breaker. But then it should be accessible in all code and (external) code should be able to implement behavior as well.
Re: How Go detects struct copies with sync.noCopy
#9Earlier quoted context omitted.
Most languages would encode such behavior in a trait or a protocol instead of a zero-length struct field. It's type information and ought to be encoded in the type. From that perspective, I think it is a hack.
This feels like a style complaint and not one about substance. An inaccessible (because it's named _) zero-length struct field is just another kind of metadata. It also doesn't require you to pollute the method set, which would be a bigger issue. The real hack to me is that anything which simply has Lock() and Unlock() methods is considered uncopyable.
Coming from Rust anyway (can't say I'm familiar with Go), nothing about having it as a trait would pollute the method set, traits don't have to have methods (e.g. pin, unpin, send, sync, etc.). Yes a zero length field can be metadata and this is a style complaint but a struct's fields are traditionally its data and the type is its metadata, I feel like it's harmful to mix these two as I at least wouldn't generally look at fields to find metadata for the struct.
Re: How Go detects struct copies with sync.noCopy
#10> noCopy is a special marker for types that must not be copied after their first use. if it looks like a hack, walks like a hack, and quacks like a hack...
I'd want to blame Go's compatibility guarantee for this, but I can't because it wouldn't actually stop them from adding a proper solution for this..
Just like the magic comments, it's a sad thing to see appear in this language because it feels like magic incantations one has to know that bend over backwards to not actually extend the language to fit the use case.