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.
