On Sunday, 9 September 2018 05:58:46 UTC+2, Robert Engels wrote: > > For the math operator, since Go already doesn’t do automatic numeric > conversions, all of the operators are almost trivially implemented as > methods, e.g. operator + is > > The point is that without "intrinsic generics" supplied by the compile *by construction*, operators would be terribly onerous to define and the language much less familiar. My point, leaning on Ignazio's lucid presentation, is to strip out the syntactic sugar provided by the compiler, then list each of the distinguishable operators (numeric conversions come into that, too, which almost certainly have a role to play in the final shape this exercise will take) and try to fathom how the compiler gets to summarise these, then attempt to formalise the process so a programmer can express it without losing Go's many assets (succinctness, readability, type safety, etc.).
My own question: it is already there by convention (call it "common law"), how do we turn it into "written statute"? It looks a lot like operator overloading, but any APL user will know that isn't what it is, it is just "analogy" by convention. The neatest example in APL is the division operator, it does not become matrix division, when applied to matrices, for good reason. Angle brackets, incidentally, jar: I really, really dislike them used in this context - my extremely strong prejudice in this respect may well taint everything I say here :-). > As I pointed out in the sample code in another thread, Java is type-safe > but still allows you to encounter a runtime type exception - so not fully > type safe, and it hasn’t stopped its adoption or success. > > Java isn't anything to be copied here, as I perhaps unkindly mentioned elsewhere: this is the wrong choir. > I’ll say it again, focus on the 90% most useful/helpful constructs, maybe > with some limitations, and be done with it. > > I think the current proposal attempts that, as elegantly as current consensus permits and in general I've found that the Go developers have a keen sense of elegance I have occasionally had to admit is both more astute and more pragmatic than anything I could muster up. But generics and Go as we know it are in conflict except where intrinsic generics are concerned and my perception is that we need to look there for the answer if only because we've swallowed that bitter pill, so an additional dose isn't really going to make anything worse. The pressure to add generics to Go 2 to address some perceived "need" is both good and bad, I'm hoping the Go developers will pull a rabbit out of that hat. > You can already shoot yourself in the foot with unsafe or CGO, why does > the generics support need to be any different... > > I do neither, perhaps out of necessity or lack of imagination, and I guess I could manage as I have until now without generics, too. But I think Go 2 deserves the fine analysis that stops it from being a second-generation committee product (SSH-2 comes to mind, I'm hoping one of those is enough deterrent). Lucio. -- 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.
