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 >>> >>> 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8edf65b3-f499-4446-908e-8e35d3070739n%40googlegroups.com.
