On Sun, Feb 27, 2022 at 6:33 PM robert engels <reng...@ix.netcom.com> wrote:
> 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 doesn't seem substantially different from escape analysis. Where there is also no spec or any other formal description, but just a flag to log decisions. I would expect generics to work similar in that regard. > 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 >>>> >>>> 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 > <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 > <https://groups.google.com/d/msgid/golang-nuts/D2355A50-46F9-475B-8651-5C7B117DFB2D%40ix.netcom.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/CAEkBMfHthjk9Oj5GemTRxXoeYgvOeR_hkism8og3YtWtvoJRVQ%40mail.gmail.com.
