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. -- 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.
