4 ms·

> please don't reply with "then you should keep the version below 1.20" That is literally the solution. Just remove your go.mod or keep it under 1.20, and you’

> please don't reply with "then you should keep the version below 1.20" That is literally the solution. Just remove your go.mod or keep it under 1.20, and you’ll keep the old behaviour forever. It’s the same as e.g. Rust’s edition, if you hate your life you can keep using Rust 2015 semantics to this day, and forever.

tgv 4y ago
I knew there would be someone. So if you want a feature in a higher version, update your code base. Yeah, that's what stability doesn't mean. And "it's your problem now" isn't great Go advocacy either.
- masklinn 4y ago
  There is no feature, it only sets the static evaluation of the language itself. Think for a second, if the go.mod stricture locked in the entire thing, you’d just be told to not upgrade. The entire point of the system is that it’s possible to update language-level semantics while allowing for the rest to progress for everybody. Setting go.mod means you get stdlib updates, but the semantics of the for loop does not change. And if the designers decide to add similar breaking changes in the future (change string literals or whatever), you’ll also be ignoring those.
  - tgv 4y ago
    I know what go.mod does. I'd say that was obvious from that remark in the first post. > Setting go.mod means you get stdlib updates, but the semantics of the for loop does not change. So you miss out on new features, or have to update your code base. We're back to square 1.
    - Ensorceled 4y ago
      > I know what go.mod does. You know what it does, but you don't grok it. Clearly you feel that setting go.mod is for other people and the language should match what you want.
    - masklinn 4y ago
      So your original complaint was "being able to opt into nBC is bad uwu", and now your complaint is that you want to mix and match if a future nBC change you do like comes around? What the fuck?
- jen20 4y ago
  You’re confusing stability with ossification. There must be a way to correct mistakes, lest the language and runtime just keep accumulating crap. I wish the Go team would take a MUCH firmer stance on this.

tgv 4y ago

I knew there would be someone. So if you want a feature in a higher version, update your code base. Yeah, that's what stability doesn't mean. And "it's your problem now" isn't great Go advocacy either.

masklinn 4y ago
There is no feature, it only sets the static evaluation of the language itself. Think for a second, if the go.mod stricture locked in the entire thing, you’d just be told to not upgrade. The entire point of the system is that it’s possible to update language-level semantics while allowing for the rest to progress for everybody. Setting go.mod means you get stdlib updates, but the semantics of the for loop does not change. And if the designers decide to add similar breaking changes in the future (change string literals or whatever), you’ll also be ignoring those.
- tgv 4y ago
  I know what go.mod does. I'd say that was obvious from that remark in the first post. > Setting go.mod means you get stdlib updates, but the semantics of the for loop does not change. So you miss out on new features, or have to update your code base. We're back to square 1.
  - Ensorceled 4y ago
    > I know what go.mod does. You know what it does, but you don't grok it. Clearly you feel that setting go.mod is for other people and the language should match what you want.
  - masklinn 4y ago
    So your original complaint was "being able to opt into nBC is bad uwu", and now your complaint is that you want to mix and match if a future nBC change you do like comes around? What the fuck?
jen20 4y ago
You’re confusing stability with ossification. There must be a way to correct mistakes, lest the language and runtime just keep accumulating crap. I wish the Go team would take a MUCH firmer stance on this.