Hi, On Wed, Dec 30, 2020 at 8:16 PM Jeremy French <jer...@frenches.com> wrote:
> This discussion bears a lot of similarity to the argument about > inheritance, and Go solved that issue rather elegantly with interfaces - > describe the behavior you need instead of the types you'll accept. I'm > wondering if there's a way to do the same thing with this problem. I'm confused by this sentence, because the rest of your message seems to describe Generics. Perhaps a different way to define constraints, but the base mechanic of "enable a function to specify a set of types that might be used and work generally over them" seems to be implied by what you write. And that's what I would call "generics". (FTR, BTW: Interfaces don't really solve the same problem set as inheritance would. Embedding is intended to address the same problem as inheritance, though. Interfaces are rather intended to solve a subset of the problems generics solve as well, namely have one function work with a variety of different types) As I understand the proposal right now (and honestly, I don't understand it > fully, and that's part of the issue) > I think it's important to remember that the generics design draft is intended to fully discuss the design, including edge-cases, implementation issues, how it would address different use-cases, open questions and possible answers. It's not intended as teaching material or specification. Personally, I would expect the actual specification of the design to be around as long and around as complex as the "Properties of types and values" section in the spec - perhaps a bit longer, perhaps a bit shorter https://golang.org/ref/spec#Properties_of_types_and_values a function signature can either say "I will only accept a value with type > X" or "I will accept a value with any type." > Not quite. Functions can already do this. It's that they can accept *types* (not values). And they can specify an (possibly empty) interface the type must implement, or a list of types that might be used (or both). > Could there be another option? In Ian's reversing example, could the > function signature say "I will accept an integer or a string, (but not a > struct or a map)"? > Yes, the design supports this already (though, FTR, for that particular function you really want it to work over *any* slice type, no matter what the element type is). > Or even better - Is there a way for the function signature to say, "I will > accept any type that can be compared as greater-than or less-than"? This > feels very Go-y. > This will also be possible, using a new `constraints` package (or similar). That is, there will be a `constraints.Ordered` and similar for this purpose. That way, by looking at the signature, you know what the function is going > to try to be doing with it. But you also get the benefit of not having to > write and maintain two essentially identical pieces of code that differ > only by their type. > > This is less than half an idea, because I don't know exactly how you would > do that. I'm hoping this thought will spur creativity in someone else. > Maybe there could be some built in "generics" (using this term in a > different way) like "Comparable" or "Addable" or "Sortable" or something, > and you could use those keywords as a type in your function signature, but > under the covers, the compiler would determine whether the value's type > conforms. That's not a great idea, but maybe someone can improve on it? > > Or could there be something similar to interfaces, where a property (or > set of properties) could be required instead of a set of methods? Could > built-in primitive types have properties added as Comparable or Addable or > something? Again, this solution feels clunky and not the right answer, but > it feels like there's a great solution somewhere in this direction. > > On Wed, Dec 30, 2020, 8:37 AM Vivi <createmap4...@gmail.com> wrote: > >> I'm sure my thought is off-topic and is not applicable, I shall give a >> try after seeing the trends in programming and non-programming world. There >> is an "overlap" between Generic and non-Generic. If it can be solve between >> the two sides, that's easy with "translation" to and back? >> >> When we have a language barrier, Google Translator makes that possible or >> ignore everything I said here. >> When Go can cross-compile to different OS architectures, it could be >> applicable for source code as well. >> >> On Wednesday, 30 December 2020 at 20:27:15 UTC+8 Space A. wrote: >> >>> Go doesn't have classes and is not an OOP language. >>> >>> Classes (like in Java) vs structs (like in Go) is about inheritance vs >>> composition, not about attaching fields and methods. Inheritance implies >>> type hierarchy, child and parent, virtual functions, abstract and final >>> implementations and so on so forth to keep this all of this manageable. >>> >>> >>> >>> вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov: >>> >>>> Please, stop being so condescending to newcomers and non-professional >>>> developers. Generics as uses by end-users will improve their experience, >>>> not make it harder. >>>> >>>> (And what is this obsession with "classes"? Go has them - structs with >>>> methods are classes). >>>> >>>> On Tuesday, December 29, 2020 at 1:32:30 AM UTC-8 >>>> rickti...@googlemail.com wrote: >>>> >>>>> My point of view is that Generics should not become part of the Go >>>>> standard library. I appreciate there are use cases where it is very >>>>> helpful >>>>> to have, but I do not believe that adds value to Go. The real value for Go >>>>> is it's simplicity, avoidance of generics and avoidance of classes. This >>>>> makes the language accessible and approachable to all, which is >>>>> increasingly more valuable. Go appeals to new-comers and experienced >>>>> developers because it is simple, and comfortable. The rate of uptake in >>>>> computing technology is still subject to Moores law, and today we see a >>>>> new >>>>> type of programmer emerging, the 'citizen developer'. >>>>> >>>>> Go follows time proven computational concepts, it does not follow the >>>>> 'new paradigm' tribes, it's roots are firmly planted in statically typed >>>>> procedural/functional programming techniques, and this maps well to much >>>>> of >>>>> the literature available. The growth of entry level developers ( aka >>>>> 'citizen developers' ) will be exponential over the next decade, and in >>>>> that landscape it is Go's simplicity that will win the day. >>>>> >>>>> On Monday, 28 December 2020 at 17:35:40 UTC L Godioleskky wrote: >>>>> >>>>>> " If generics gets added to Go, we're opening a very dangerous door, >>>>>> and >>>>>> it will be the downfall of Go because - and Robert Griesemer this is >>>>>> especially addressed to you - what's next then? Seriously, what's >>>>>> next? ... " >>>>>> >>>>>> .. AI, followed by cryto currency and asexual repoduction >>>>>> On Tuesday, December 22, 2020 at 5:09:05 AM UTC-5 Martin Hanson wrote: >>>>>> >>>>>>> No polls. It's not a matter of majority rule! >>>>>>> >>>>>>> It's a matter of understanding why generics was left out of Go from >>>>>>> the >>>>>>> start, like classes was left out of Go. If we start adding stuff >>>>>>> that >>>>>>> the original developers of Go left out by purpose, we're not >>>>>>> understanding the design choices that went into Go, which is exactly >>>>>>> what makes Go unique! >>>>>>> >>>>>>> Go was a major slap in the face to all the hype that has polluted >>>>>>> the >>>>>>> programming industry for the past 30-40 years, which is why Go got >>>>>>> so >>>>>>> much hate in the beginning from all the hype loving people. >>>>>>> >>>>>>> If you want to add generics to Go, if you want to change how errors >>>>>>> are >>>>>>> handled, if you want X, Y or Z feature that Java, C++, or some other >>>>>>> complex language has got, then go use that language! Why are you >>>>>>> even >>>>>>> here!? >>>>>>> >>>>>>> The design choices that went into Go was not made randomly, nor were >>>>>>> they made by just anyone. Please understand that the people who >>>>>>> designed Go, and we all know who they are, had/has tons of >>>>>>> experience >>>>>>> and the pragmatic approach they took is what make Go stand out so >>>>>>> beautifully! >>>>>>> >>>>>>> If generics gets added to Go, we're opening a very dangerous door, >>>>>>> and >>>>>>> it will be the downfall of Go because - and Robert Griesemer this is >>>>>>> especially addressed to you - what's next then? Seriously, what's >>>>>>> next? >>>>>>> Let the community decide by majority!? Is that how we design a >>>>>>> professional programming language now? By majority rule?! NO! The >>>>>>> majority is all about hype and shine. >>>>>>> >>>>>>> Adding generics to Go will rip out the spine of the philosophy of Go >>>>>>> and I for one will not be a part of that. I have more than 30 years >>>>>>> of >>>>>>> experience in the business and I fully understand why generics and >>>>>>> classes and all the other clutter was left out of Go. >>>>>>> >>>>>>> If generics gets added to Go, we're a big enough part of the >>>>>>> community, >>>>>>> that passionately hate that, that we can manage to fork Go - which I >>>>>>> strongly believe will then be the right thing to do! >>>>>>> >>>>>> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/LEEuJPOg0oo/unsubscribe. >> To unsubscribe from this group and all its topics, 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/cef57f9c-f641-4887-8cca-675613e8be37n%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/cef57f9c-f641-4887-8cca-675613e8be37n%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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CA%2Bj6mhDjqjXVMJ8q52cYDKfxrf9dUA90kuB%2BTg2G57KtCEiPWg%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CA%2Bj6mhDjqjXVMJ8q52cYDKfxrf9dUA90kuB%2BTg2G57KtCEiPWg%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/CAEkBMfEu1-3d1EkwzyOkgnXxrdmnp_uhc6AGRXRmgUq%2BZeRUpg%40mail.gmail.com.
