Is a variation on Templates a better way for Generics?

[Kevin Chadwick]

I'm wondering. Would it be better to have say a template in a folder that is
used to generate all the various typed Golang ready for the compiler.

This way the code would be fully typed and could be maintained in one place. The
compiler could maybe still be as fast as today post generation and the untyped
code ignored and the generated typed code read more easily as standard code?

[Kevin Chadwick]

Maybe the compiler could switch between the generated imports depending on the
type in question?

[Ian Lance Taylor]

There are existing tools that work that way for Go. They can be
awkward for cases where you need to instantiate a type with a generic
type, as in List(List(int)). They don't tend to help much with
compilation time overall, as each package that needs a generic type
needs to instantiate the template itself, so you get lots of
duplicates that all get compiled. Debugging is awkward as the
debugger doesn't know anything about the copies.

Ian

[Kevin Chadwick]

I was mainly thinking that having duplicate code with typed syntax would be more
understandable and a substantial advantage over new generic syntax that requires
further interpretation by the reader. The generated .go files could also teach
how to write the generic code. Sounds like it may have already been considered
and ruled out though.

[Ian Lance Taylor]

Personally, when it comes to interpretation by the reader, I think
that the new generic syntax in the design draft is fairly minor. I
don't see how a template based approach will be any clearer; it won't
be less clear, but I don't see why it will be clearer. Perhaps you
could write down a couple of short examples to show why using
templates would be clearer for the reader.

Ian

[Kevin Chadwick]

On 2020-08-01 18:34, Ian Lance Taylor wrote:
> Personally, when it comes to interpretation by the reader, I think
> that the new generic syntax in the design draft is fairly minor. I
> don't see how a template based approach will be any clearer; it won't
> be less clear, but I don't see why it will be clearer. Perhaps you
> could write down a couple of short examples to show why using
> templates would be clearer for the reader.

I'm thinking (whilst likely missing some important things) that a reader
wouldn't even need to know the Generics syntax to understand the executed code.
Just the author. To become an author, the reader could look at the templates
compared to the .go code output. It's certainly true that it wouldn't be worth
the effort, if the Generic syntax is easily understood anyway.

However, I'm not sure the following is a trivial amount of work to understand,
especially if it becomes part of a more complex piece of code?

"https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md"

[Ian Lance Taylor]

I agree that the design draft is not trivial to understand, but,
similar to what you suggest, I hope that readers can understand it
clearly. See the examples. And don't forget that even with
templates, there will have to be some way to describe what types are
permitted, which is the source of much of the complexity in the
current design draft.

Ian