Real use cases have been provided it appears for both why generics can be good and how they can be used negligently (love the sextuple example BTW). I know many things in programming can be used the wrong way but does generics potentially cross a threshold where the writer should add an import to ensure that the writer is a "library" writer and not someone that doesn't understand the benefits?
A simple import like unsafe that would be a "marker" (probably called something better) that would be sufficient to have new programmers not assume they should always use generics while enabling more advanced users to declare they are intentionally writing generic functions might be an easy middle ground. Potentially the marker may also enable some future optimizations. Forgive me if that has already been suggested in a thread that I missed. If it has, would love to know why adding a marker as a way to maintain the simplicity that others fear will be lost was not something that makes sense here. Sincerely, David On Thursday, December 31, 2020 at 2:02:53 PM UTC-6 Ian Lance Taylor wrote: > On Thu, Dec 31, 2020 at 5:42 AM Kevin Chadwick <m8il...@gmail.com> wrote: > > > > On 12/30/20 6:38 PM, Ian Lance Taylor wrote: > > > I don't think this is accurate. Surveys express a clear and > > > consistent desire for generics that is far ahead of requests for > > > operator overloading or other language features. (To avoid > > > misunderstanding I'll say again that changes to the Go language are > > > not driven by polls.) > > > > Firstly, I appreciate that dev is not driven by polls but it may be that > > internally to Google these desires are true too. It is natural to be > less likely > > to get an honest answer from many employees, of course. > > I'm confident that Google employees are entirely willing to honestly > express their feelings about Go. There is no company mandate to use > Go, or to like it. (Of course I have no way to prove this.) I > haven't seen any reason to think that Google employees are either more > or less likely to prefer adding generics to Go than people outside of > Google. It's not necessarily obvious, but there are Google employees > on golang-nuts arguing that Go doesn't need generics. > > > > If Generics is something wanted by the designers without or little > debate aside > > from the form, then just say so and end the discussion? > > I don't think it's that simple. For a long time now the Go FAQ has > said "Generics are convenient but they come at a cost in complexity in > the type system and run-time. We haven't yet found a design that gives > value proportionate to the complexity, although we continue to think > about it." What we are considering now is whether the current design > draft gives value proportionate to the complexity. I like to think > that it does, but obviously I am biased. And the only way to avoid > that bias is to open up the discussion to the community, which is what > we've been doing over the last couple of years. > > In other words, sure, we could say "we want generics." And I think > that for many of the language designers that is a true statement. But > it's also true that we only want generics if the language can remain > sufficiently simple and easy to use. So the bare statement "we want > generics" doesn't get us anywhere useful. It doesn't end the > discussion. It just starts it. > > > > Also, whilst understanding that voluntary submission has it's benefits > in terms > > of avoiding suggestion; that data has already been acquired. I wonder > what the > > result would be given a number of options. I probably can't think of > many of the > > good requests, so this could be fuelled by past submissions. I can't > remember > > hitting a null pointer in my code but certainly have in stdlib network > libraries > > (missing an & etc.) > > > > > > Null pointer panic avoidance via automatic error return (what happened > before > > panics?) > > > > enhanced Gomobile support > > > > enhanced tinygo support > > > > Generics > > > > Flutter, Go cooperation > > > > ... > > > > No changes > > These are all very different kinds of things. For example, I think > it's a category error to think that working on generics somehow means > that we have worse Gomobile support. To the best of my knowledge, the > people working on generics have never worked on Gomobile, and > vice-versa. > > Ian > -- 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/672538d4-d313-4e60-bc39-bbe56f0c401dn%40googlegroups.com.
