I disagree that it wont be formally published - or at least have knobs to turn to control it - otherwise it will be nearly impossible to make the determination of when your generic’s usage will result in a performance penalty. This probably won’t matter for 95% of the code - but it if does matter - your only solution would be to always avoid generics and roll your own - which defeats the purpose.
I can see build labels controlling the generation options. > On Feb 26, 2022, at 5:51 PM, Ugorji Nwoke <ugo...@gmail.com> wrote: > > To your direct questions, the answer is a mix of both: C++ style where the > generic block is a template and code is essentially generated for each type > known at compile time with static dispatch, and java-like where it is similar > to an interface call with dynamic dispatch. The compiler will strike the > right balance of binary size, compile time and execution speed. To follow its > heuristics rules (which will likely not be formally published to prevent > people from depending on it), you might have to stay close to the development > for that. > > On Friday, February 25, 2022 at 5:15:47 AM UTC-5 markus....@gain.pro wrote: > Correction: > > - it must be possible to express that T is comparable (so that you can use > map[K]V, were K must be comparable) > - it must be possible restrict T to a concrete list of types (f.e. min(a, b > T) T must be possible to write) > > On Friday, February 25, 2022 at 11:13:01 AM UTC+1 Markus Heukelom wrote: > I think the consensus in the Go community is to refrain from comparing Go > language features with other programming languages. Rationale ~: > > - it is highly contentious > - it is very difficult to answer, it's like asking "is purple more blue or > more red" > - no matter the answer, it will not help you a lot to write better programs > or be more productive in Go > > However, maybe your real question is more like "what are/were the guiding > principals for generics in Go?". As far as I understand, generics in Go > follow the same principles as other language features in Go: > > - compilation should be very fast, but trade-offs are allowed so it does not > need to be maximally fast > - language features should be as orthogonal as possible, but trade-offs are > allowed so they don't need to be maximally orthogonal > - it should be a simple as possible but no simpler > - ... > > For generics this has resulted in: > > - exotic use-cases are not supported (for example having an integer > *constant* as *generic parameter*, such as you see in C++ fixed size matrix > templates, is not supported) > - it must be possible to express that T is comparable (f.e. min(a, b T) T > must be possible to write) > - it must be possible restrict T to a concrete list of types > - it must be possible to restrict T to a type with method set that equals > that of some interface (I *personally* think this violates the principle of > orthogonality too much and will lead to confusion and design debate) > > Of course, neither list is exhaustive and is only my personal understanding > of things. > > -Markus > > On Wednesday, February 23, 2022 at 9:41:14 PM UTC+1 Jason E. Aten wrote: > Back in 2009, Russ wrote a blog on generics, talking about the tradeoffs in > providing generics: > > "The generic dilemma is this: do you want slow programmers, slow compilers > and bloated binaries, or slow execution times? " -- > https://research.swtch.com/generic <https://research.swtch.com/generic> > > I haven't had the bandwidth to follow the generics detailed discussions. I > was just curious, at a high level, for creating a mental model of Go's > generics: which approach was taken? > > Thanks! > > J > > -- > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/8edf65b3-f499-4446-908e-8e35d3070739n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/8edf65b3-f499-4446-908e-8e35d3070739n%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/D2355A50-46F9-475B-8651-5C7B117DFB2D%40ix.netcom.com.
