3 ms·
For this particular case they thought ahead and require implementations to work with a GC that might move pointers. You run into it with cgo, which, as a result
by cdoxsey 8y ago
For this particular case they thought ahead and require implementations to work with a GC that might move pointers. You run into it with cgo, which, as a result, has quite arcane rules for passing data between the two: https://golang.org/cmd/cgo/#hdr-Passing_pointers https://golang.org/cmd/cgo/#hdr-Passing_pointers
Like with randomizing hashmap keys, they randomly enforce the rule to make sure that no one relies on it just happening to work since Go's GC doesn't currently move pointers.
- Jabbles 8y agoI don't understand - as you say, cgo requires extra rules. Are you suggesting that extra rules will apply every time you cross a particular Go version boundary? This proposal doesn't seem to suggest that.
- cdoxsey 8y agoSorry for the confusion. The rules were put in place to leave open the possibility of GC which could move pointers. Its not really related to this proposal directly, but its an example of how you can define a feature in such a way as to allow future changes.