The title of your message seems to indicate that you are looking for arguments not to implement generics. You should be aware that the proposal to add generics has been accepted <https://github.com/golang/go/issues/43651#issuecomment-776944155>, so the discussion of whether or not Go will get generics is answered. For better or for worse.
With that in mind: I am not aware of any extensive or formal evaluation like the one you are looking for. And I don't think it is common to do such an evaluation for any language change proposal in Go, beyond what individuals estimate for projects they take on and the Go team planning their workload. It is possible someone on the Go team (or someone else) has more data though. The discussion went on for several years and included many of the people working on the official Go compiler. The consensus seems to be, that the work required is not unreasonable. I am not personally aware of any of them raising concerns about the workload (though I might have missed something and/or I might've not been aware that someone voicing a concern was working on the compiler, so take that with a grain of salt). As for third-party implementations: In general, it is up to the respective projects if and how they want to implement language changes. Planning that is not usually done in the context of the Go project. That being said, over the past 3 years or so there was plenty of occasion for any third party implementer to voice any concerns. I am not personally aware of any of them doing so (same caveats as above). My own uneducated guess is that implementing the design is not prohibitively difficult. The syntactical changes are very small. The type inference algorithm is fairly simple. And a simple implementation can instantiate the generic types and functions early in the frontend, without having to modify many internals. Generics are a big language change in terms of expressive power of the language and a language change in terms of amount of discussion to get it right. But I suspect in terms of changes to the spec and implementations, it will be a surprisingly small change. I'm sorry for a whole lot of "I don't know" - and maybe someone who knows more will add more. But as someone who was pretty actively participating in the discussion for the past several years, I wanted to re-assure you that "it is too much work to implement" is not really a concern shared by many, as far as I can tell :) On Fri, Mar 12, 2021 at 4:31 PM alex-coder <a.gusse...@gmail.com> wrote: > Hello again, > I apologize for being so intrusive. > Where it is possible to read about the evaluations of labor and complexity > for > GO itself for different implementations to introduce generic in GO ? > > Thank you. > > -- > 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/64e6d441-3564-49ab-9f97-233eda3ea682n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/64e6d441-3564-49ab-9f97-233eda3ea682n%40googlegroups.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/CAEkBMfEE%3DHbr%3D2HzsWA21GQdkXj33iqRJvT6jO_wHC-X-U1%3DBg%40mail.gmail.com.
