>- 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)
Does a longer (but not necessarily exhaustive) list of the unsupported exotic use cases exist? This would be useful to understand all of the situations where Go generics cannot (or should not?) be used. Glen On Friday, February 25, 2022 at 5:13:01 AM UTC-5 markus....@gain.pro 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/25a18a9a-45ae-43f7-b403-4cdf7f310b07n%40googlegroups.com.
