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/3740af77-31f0-4423-b264-aaeb0cfbe49dn%40googlegroups.com.
