3 ms·
I need Go to take one lesson from rust and that’s specifying if a function will mutate values passed through it or not. This can technically be done as a break
by aaomidi 3y ago
I need Go to take one lesson from rust and that’s specifying if a function will mutate values passed through it or not.
This can technically be done as a breaking change spread over several versions of go and I think the cost would be worth what we’d get out of it. Utilities can also be made to edit code to support this automatically without having to have some user go fix it all.
Basically, I want an introduction of either a function level or value level ‘nut’ keyword like Rust where the function can not mutate a field unless it has explicitly stated mut.
This would fundamentally solve a whole class of bugs and errors that happen in go where some library ends up modifying a struct (pointer or a struct with a pointer field) without the caller intending that.
- aatd86 3y agoI'm not sure I fully understand what you're proposing? Is it about function purity or immutable values? I think the way to do the latter in Go is to not export the field and only have it modifiable by a dedicated method. (or even enforce copy-on-write). And passing values instead of pointers where needed. I don't think that breaking compatibility to add a mut keyword would fit Go. It makes more sense for rust. (especially wrt interior mutability... That would make it a very pervasive change, probably too much of a change) Another thing is that wrapping values in an empty interface essentially make those immutable. It doesn't necessarily have mechanical sympathy but as long as you don't wrap pointers, it would be difficult to modify (no aliasing). Then again, it's more defensive and pragmatic coding than something that proves functional purity. Seems that it is enough.