3 ms·
The slightly less obvious story here: this is a breaking change to Go, and they’ve managed to find a policy whereby such a change is permissible. I think that’s
by philosopher1234 3y ago
The slightly less obvious story here: this is a breaking change to Go, and they’ve managed to find a policy whereby such a change is permissible. I think that’s the more substantial development, though this is quite an ugly wart and I’m glad it’s off.
- GauntletWizard 3y agoYeah, I like this change, but I would like this change for Golang 2.0.
- pansa2 3y agoAgreed. The change (especially to for-range) is a good one, but IMO they shouldn’t be breaking the Go 1.x Compatibility Promise in a Go 1.x release.
- arp242 3y ago"Go 2" will most likely never happen. It was always a placeholder for "yeah, this might be a good idea, but we can't do it now as it would break compatibility".
- legobmw99 3y agoThis doesn’t sound that different from e.g. Rust’s Editions, though it seems like it can occur much more frequently
- philosopher1234 3y agoI dont really know much about Rust editions, but what little I do know sounds at least similar. Heres the issue where they changed the backcompat policy: https://github.com/golang/go/issues/56986 https://github.com/golang/go/issues/56986
- j16sdiz 3y agoI would rather not have this. The worse thing is: the old code still compile in new /old version. There is no error or warning. Updating the version is so innocent looking. Nobody will be able to catch this error.
- philosopher1234 3y agoI can't tell if you've read the issue based on your comment, but I recommend it. They go to great lengths to address this concern.