I thought that hiding generics behind a flag is already a thing in Go 1.17?
If a feature is solid enough for stable release, don't make it an opt-out. People can just avoid the language features they don't want to use. I disagree with the suggestion of adding stuffs to go.mod to enable or disable certain language features. If you are releasing a library for production and/or a public consumption, it should be stable enough that you don't need to include experimental language stuffs. If you include experimental stuffs in your projects, it is generally for your own toy projects that you should know well enough that you need to enable certain flags when building. No change to go.mod is necessary. Don't split the ecosystem. The last thing we need are libraries that are incompatible with one another. That happened to D. Even though they fixed it with D2, the language lost its moments and never recovered. I like D, but it is not a fad anymore and not many people use it. On Wednesday, October 13, 2021 at 6:05:54 PM UTC+7 axel.wa...@googlemail.com wrote: > On Wed, Oct 13, 2021 at 11:36 AM roger peppe <rogp...@gmail.com> wrote: > >> ISTM that in a sense, generics *are* behind a flag in 1.18, on a >> per-module basis at any rate - if your go.mod file doesn't declare a Go >> version of at least 1.18, then you can't use type parameters. >> > > The (important) difference being that with a flag, we'd generally reserve > the right to change the behavior in the future, should experimentation show > it to be deficient, while this way, we can't - once we release generics, we > are bound to that. And setting there is no way to opt in to other aspects > of go 1.18 *without* also getting generics. > > I guess in theory we could have a `language_experiments = (generics)` (or > something) directive in go.mod, to *actually* get per-module opt-in to > "beta-features". AIUI that's kind of what Haskell does. This might still > split the ecosystem, though. > > >> >> >> >>> >>> >>> > On Monday, October 11, 2021 at 5:26:35 PM UTC+13 Ian Lance Taylor >>> wrote: >>> >> >>> >> On Sun, Oct 10, 2021 at 2:55 AM nil...@gmail.com <nil...@gmail.com> >>> wrote: >>> >> > >>> >> > We are really excited about the coming generics support in Go, our >>> test drive of the generics support in 1.17 is so far pretty positive and it >>> would also allow us to immediately delete tens of thousands lines of code >>> from our main project. >>> >> > >>> >> > Our understanding is that Go team's current plan is to have the >>> generics support enabled by default in the 1.18 release scheduled for Feb >>> 2022. The question we are facing now is how much certainty we have on that. >>> I mean if generics could get delayed until 1.19, which would be 10 months >>> from now, then we should probably wait rather than switching to the full >>> use of generics now. >>> >> > >>> >> > Could someone from the Go team provide us some guidance please? >>> Shall we wait until the coming code freeze or maybe beta1 to expect more >>> clarification? >>> >> >>> >> The current expectation is that Go 1.18 will support generics. The >>> >> tip Go compiler already supports generics. There are bugs, but as >>> >> they are reported they are being fixed. It is reasonably likely that >>> >> some generics corner cases will not compile in Go 1.18, but the >>> >> expectation is that straightforward uses of generics will work as >>> >> expected. It is also likely that performance in Go 1.18 will not be >>> >> as good as it will be in later releases. >>> >> >>> >> Of course, it's impossible to guarantee this. Something completely >>> >> unexpected could happen. But that is the expectation. Hope this >>> >> helps. >>> >> >>> >> Ian >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> > To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/a2b05910-9cdc-4fb4-94d5-61bd12812089n%40googlegroups.com >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUK64FN9%3DYuo0xFTfAz%2Ban8eq9vwgX9rkcFsAdU0P%3DkfQ%40mail.gmail.com >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAJhgacjO%2BjhB0WyV1H1vJxXxymP7gkvdNoqvZuHngkEVd3DURw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAJhgacjO%2BjhB0WyV1H1vJxXxymP7gkvdNoqvZuHngkEVd3DURw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1079497d-b665-48c4-9c36-aecac4b74c9cn%40googlegroups.com.
