On Tuesday, October 16, 2018 at 6:05:56 PM UTC+1, Eric Raymond wrote: > > > > On Tuesday, October 16, 2018 at 12:24:59 PM UTC-4, alanfo wrote: >> >> With regard to your reply to Ian, I'm afraid I can't agree with you that >> the type parameters shouldn't be specified 'up front'. That's just too >> 'dynamic' for me and not very go-like. I'd imagine it would give the >> compiler all sorts of problems and anyone reading the code would wonder >> whether T, Node, Edge etc. were concrete types defined elsewhere in the >> package or type parameters of a generic function. >> > > So now we get to the philosophical issue. Why and when do I *care* > whether I'm looking at a concrete type or type parameter? > > I maintain that normally I don't - it only matters to me what contract the > type is expected to satisfy, and that should be clear from looking at its > callsites. If it isn't clear, that's a problem that heavier notation won't > solve. > > I've already thought of a compilation strategy for this. It's not a new > problem; I had to think about a closely parallel case in Lisp around 1980. >
I don't think you can disregard philosophical aspects in language design. Whatever proposal for generics is finally settled on needs to be a good fit for the language, consistent with its ethos and not impact too adversely on compilation time which has always been one of Go's strengths. At the end of the day Go is a statically typed C-family language and is nothing like either Lisp or Python. As such Go users have different expectations to users of a dynamically typed language. Perhaps I'm wrong about this (as ILT didn't rule it out as I expected him to) but when I see a function definition I want to know immediately about its return type, the types of its parameters and, if it involves parameterized types, I want to know about them too. I don't want to search for an instantiation of the function to figure out which is which. Now you've said that you dislike the syntax which Ian and Robert came up with for defining type parameters which is fair enough (though personally I did like it) and it may be that there are simpler ways of differentiating type parameters from normal parameters (such as preceding the former with a tick or something) which would fit this proposal better. All I'm saying is that I'd like to know which is which when the function is defined and I'd have thought that most other Go users would say the same. Alan -- 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.
