This evening I was thinking about the parts of the Type Parameters draft design that are not interface types per se, and I went back over the section on pointer methods <https://golang.org/design/go2draft-type-parameters#pointer-methods>.
It struck me as odd, because the second example (described as “awkward”) is *very* similar to what would be needed to implement an append function on par with the existing, built-in append: namely, one <https://github.com/bcmills/go2go/blob/master/append2.go2> or two <https://github.com/bcmills/go2go/blob/master/append3.go2> additional type parameters that can almost always be inferred, but that must be related in some way to the the composite type underlying the first parameter. Unfortunately, the solution proposed for pointer receivers does not help at all with append, or with similar functional APIs (think slices.Map or channels.Reduce). (https://golang.org/issue/39661 contains descriptions of several similar examples. The special case for pointer receivers doesn't strike me as horrible, but it seems like a special case for a general problem that is left unsolved — and would need to be carried forward as a warty special case into the indefinite future, even if we eventually *also* address the general problem. I think we should avoid committing to the special case for pointers until we have had a chance to consider improvements to the type-unification algorithm in more depth. -- 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/CAKWVi_QyqG48cymHEv2AAXfbfN9CMFVvxB2vqSgf%3DTk87SRm3Q%40mail.gmail.com.
