I understand the difference, but that doesn't prevent me from having to choose between the two implementations. To simplify greatly, and as you pointed out in your reply, there is a tension between "simplicity" (non-generic) and "performance" (generic), and that is where I fear the friction will come from.
Looking beyond the syntax, the code for both implementations expresses exactly the same thing. So in a way it is the syntax that forces the choice to be made at the time the function is written. What I would like is not to have to make the choice at the time that I write the function, but perhaps this wish is impossible given the current Go syntax. Arnaud On Sunday, 27 December 2020 at 17:32:48 UTC k.alex...@gmail.com wrote: > Since in this case the use of generics doesn't let you do anything new, I > would argue that the KISS principle applies and the non-generic version > should be preferred. > > I think a linter can be added to go vet to warn about instances like this > one (where the type parameter can be replaced by the type bound) to > encourage simplicity. > > But as Ian pointed out, in the version that takes a slice argument, using > generics does allow you to do something you couldn't do otherwise (without > reallocating the contents of the slice to effect a "cast" to []Stringer). > In this case using generics actually makes the caller's job simpler and > improves performance by avoiding the need for reallocation. > > On Sun, Dec 27, 2020 at 4:23 AM Arnaud Delobelle <arn...@gmail.com> wrote: > >> In my opinion, the issue is that there are two ways to express (almost) >> the same thing and that in itself creates friction in the language. >> >> There may be a valid reason to choose one version over the other, but >> every time it will be necessary to review the pros and cons of each >> alternative. >> >> If we could have "generics" without having to make this choice it would >> unblock the whole thing as far as I am concerned. >> >> Cheers >> >> On Sun, 27 Dec 2020, 05:25 K. Alex Mills, <k.alex...@gmail.com> wrote: >> >>> While it depends on the final generics implementation, my understanding >>> of how things stand now is that Print would compile down to a separate >>> chunk of binary for each type T that is used. For instance, if you used >>> Print[A] and Print[B] in your code, they would each refer to separate >>> binary implementations in which T is replaced by A and B, respectively. >>> >>> Printi does not do this, so you should see a smaller binary. >>> >>> IIRC, Printi also has to do a bit of work to lookup the Stringer method >>> on the type inhabiting the interface. I don't think that creates a >>> significant performance hit, but I might be understating the overhead of >>> interface dispatch. A benchmark would help here (alas, I am on my phone). >>> >>> With respect for the concerns mentioned above, I don't see an argument >>> for preferring Print over Printi. However, there may other concerns which I >>> am unaware of. >>> >>> On Sat, Dec 26, 2020, 9:58 PM Elliot <z11...@gmail.com> wrote: >>> >>>> If we remove slice from OP's example: >>>> >>>> https://go2goplay.golang.org/p/KSJpRw1Lrmm >>>> >>>> func Print[T Stringer](s T) { >>>> fmt.Print(s.String()) >>>> } >>>> >>>> func Printi(s Stringer) { >>>> fmt.Print(s.String()) >>>> } >>>> >>>> Are these two equivalent? When should one be chosen over the other? >>>> >>>> On Thursday, 24 December 2020 at 04:41:16 UTC+8 Henrik Johansson wrote: >>>> >>>>> Why will interfaces be more idiomatic once generics lands? It remains >>>>> to be seen I guess but I could very well see the other way become the >>>>> idiom. >>>>> >>>>> On Wed, 23 Dec 2020, 21:20 wilk, <wi...@flibuste.net> wrote: >>>>> >>>>>> On 23-12-2020, Ian Lance Taylor wrote: >>>>>> > On Wed, Dec 23, 2020 at 9:54 AM wilk <wi...@flibuste.net> wrote: >>>>>> >> >>>>>> >> https://go2goplay.golang.org/p/fTW3hJYNgfU >>>>>> >> >>>>>> >> type Stringer interface { >>>>>> >> String() string >>>>>> >> } >>>>>> >> >>>>>> >> Print[T Stringer](s []T) >>>>>> >> >>>>>> >> Print(s []Stringer) >>>>>> >> >>>>>> >> Both forms works. >>>>>> >> How to prevent double way to do the same things that can be >>>>>> confusing ? >>>>>> > >>>>>> > Both forms work but they mean two different things. >>>>>> > >>>>>> > Print(s []Stringer) takes a slice of the type Stringer. >>>>>> > >>>>>> > Print[T Stringer](s []T) takes a slice of some type T, where T >>>>>> > implements Stringer. >>>>>> > >>>>>> > For example, if MyInt implements Stringer, and I have a []MyInt, >>>>>> then >>>>>> > I can call Print[T Stringer](s []T) but I can't call Print(s >>>>>> > []Stringer), because a []Stringer is not a []MyInt. >>>>>> >>>>>> I understand the differences. But i'm affraid someone who never used >>>>>> Go before will use type parameters instead of interface which is more >>>>>> idiomatic i think. >>>>>> I mean it will be difficult to say, you could use type parameters but >>>>>> you should use interface, or something like that... >>>>>> I'm speaking about ease of learn Go2. >>>>>> >>>>>> -- >>>>>> wilk >>>>>> >>>>>> -- >>>>>> 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...@googlegroups.com. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/golang-nuts/rs08pp%24p8m%241%40ciao.gmane.io >>>>>> . >>>>>> >>>>> -- >>>> 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...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/d044ae30-7254-4a86-9cba-1bc18eeb7fefn%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/golang-nuts/d044ae30-7254-4a86-9cba-1bc18eeb7fefn%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...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CALJzkY-asEOYK1_zgVzNJ4B37u17QX0hZr5vZGADe-vEJgTtQA%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/CALJzkY-asEOYK1_zgVzNJ4B37u17QX0hZr5vZGADe-vEJgTtQA%40mail.gmail.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/859c14df-2dec-4e36-a4f0-7528bf17b8fen%40googlegroups.com.
