these seem excellent points all around. one area of difficulty seems to me the lack of operator overloading. now, hold your breath, i'm not arguing for it here. but it highlights a kind of structural issue that is in the air around the discussion of generics. consider:
i instantiate a tree type to handle uin64 data. under the proposal, this should work because guards assert that the type proposed must allow "==" to be used. i instantiate with some custom type that needs its own custom "isEqual(a,b)" -- that will not instantiate because there is no "==" operator for my custom type, even though there is an equality tester but its name is not "==" and i can't overload "Operator==" to say so. this is not an argument for operator overloading but rather the observation that what the generic tree code actually wants is not an "==" for instantiated types but the more general and less specific notion of "what can i call to determine equivalence?" one way is to have operator overloading so my type has equivalence testing under a standard name. (==) one way is to instantiate with the type name and a "test for equal" function pointer that when nil means "just use ==" one way is to annotate my type's "isEqual()" a la json annotation with a hint saying "use this for equality testing" there may be many ways. but it seems generics would be simpler and more generic if there was a way to be clear about such things. that is, to be generic we want to ignore inessential differences in instantiation, but extraneous difference (the name of equality testing) makes the essential and inessential more confused. On Fri, Sep 21, 2018 at 1:15 PM Lucio <lucio.d...@gmail.com> wrote: > > > On Friday, 21 September 2018 11:52:40 UTC+2, Louki Sumirniy wrote: >> >> This is something that I have seriously considered to be the right way >> for Go to express other generic types. I am in fact in the middle of a >> project at the moment where I have created a pair of generic byte buffer >> types, one is the regular kind, the other uses memguard locked buffers, for >> keeping secrets out of reach of other processes on a system. >> >> >>> I like this exposition and I think it has inspired me to a realisation I > have not seen mentioned in the many discussions I have tried to follow, > namely that the existing generics in Go - numeric operators and few > special-purpose intrinsic functions, have a common property: only a very > few operands, something that user generics will no doubt not be restricted > to. > > In other words, there is an overarching "contract" involved that enforces > "simplicity". I don't know what the designers of a generic polymorphism > paradigm can make of that, but I'm sure that much of the blood, sweat and > tears shed so far have been caused in an attempt to extend the complexity > of "generics" in addition to the scope of the receiver, arguments and > result lists. > > I hope this is helpful. > > The other thought I had, but is very poorly baked, is that the "essence" > of polymorphism in Go operators is analogous to the informal definition of > interfaces: it can be determined by the compiler, even though it is not > expressed in a formal notation (the magic of super-types like for example > "numerics" to which the addition operator applies). > > In a nutshell, defining a polymorphic function would entail omitting > explicit type qualifications entirely and allowing the compiler to > determine compatibility from the use of polymorphic operators and > consequently rejecting combinations that, like in interfaces, do not fit > permissible combinations of such operators. Lack of implicit conversions is > then the remaining problem and I have not found (or even sought) a solution > to that, but others' vision will no doubt be further reaching than my own. > > I'm sorry if I'm not expressing my ideas very clearly, this is stretching > my understanding somewhat. > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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. For more options, visit https://groups.google.com/d/optout.
