4 ms·
The standard library uses unsafe for syscalls, for higher-performance primitives like strings.Builder, etc, so it's support is mandatory to run any non-trivial
by nasretdinov 2y ago
The standard library uses unsafe for syscalls, for higher-performance primitives like strings.Builder, etc, so it's support is mandatory to run any non-trivial Go program
- zozbot234 2y agoSomehow I don't think Wasm-GC is going to support bare metal syscalls anytime soon. That stuff all has to be rewritten anyway if you want to target WASM.
- nasretdinov 2y agoIt's not just system calls. E.g. reflection package uses unsafe too: https://github.com/golang/go/blob/master/src/reflect/value.go https://github.com/golang/go/blob/master/src/reflect/value.g... . Many packages from Go standard library use unsafe one way or the other, so it's not fair to say that unsafe package is separate from the rest of the language
- mappu 2y agoFor a while the GOOS=nacl port and the Google App Engine ports of Go disallowed unsafe pointer manipulation too, so there is some precedent. Throughout some of the ecosystem you can see pieces of "nounsafe" build tag support (e.g. in easyjson).
- pjmlp 2y agoMost programming languages that offer unsafe, either as language keyword, or meta package (unsafe/SYSTEM/UNSAFE whatever the name), have similar option, that doesn't make it less of a feature.