Getting experience with type parameter parens

[Brian Hatfield]

In a number of mailing list responses about various concerns or suggestions regarding the specific choice of parens for type parameters, Ian has responded a few times with:

> Let's get some experience with this syntax before we decide to change it.

What does this mean, exactly?

For context, I, as I am sure you are, am seeing a lot of feedback about the choice of parens for this - on the mailing list, on Twitter, privately from peers, and even my own self doubt of feeling a bit uncertain about if I am reading the syntax correctly.

At what point is that feedback actionable? Is there a plan for making a decision before it's more difficult to change?

For clarity, I have read the design document, both a year ago, and the current revision, because I am very excited about the work that is being done. I've played with the playground, and read a few other examples and posts folks have written about the current draft.

I still feel a bit uncertain/uncomfortable. I also think initial reactions are valuable, because they can show us how immediately understandable choices are, which is important as Go welcomes new or casual developers.

TL;DR: what's next for that specific design decision?

Thank you!

Brian

[Ian Lance Taylor]

What I mean is: write some code using the syntax described in the
design draft. See what that code looks like. See if it is readable.
See if the parentheses are confusing.

The syntax used for type parameters and type arguments is the very
first thing that people will encounter when looking at generic code.
The proposed syntax is unlike that used in most other languages.
Therefore, it is the first thing that will concern people looking at
the design draft and the first thing that they will comment on.

The fact that the syntax is unusual means that people will comment but
it doesn't in itself mean that the syntax is bad. Of course, the
syntax may be bad. But we can't judge that by people's first
reaction. We can only judge that by people writing real code. We
need experience with code to know whether the syntax can work.

So, let's get some experience with this syntax before we decide to
change it. Experience, not just first impressions.

I understand your comment that initial reactions are valuable, but I
think that thoughtful experiences are more valuable. There are many
first reactions that people have to Go that cause them to bounce off
the language, like the fact that braces must be at the end of the
line, or that exporting of identifiers is done using an initial
capital letter, or that in declarations names appear before the type.
We saw many comments about those topics in the early days of Go. But
as people got used to these ideas, and they turned out to be OK.
Perhaps parentheses for type arguments will also turn out OK. Perhaps
not. We'll see.

You express a concern that it's difficult to change the syntax, but
it's not. It's trivial. If we keep the basic idea of type parameters
and type arguments, it will be easy to automatically rewrite any code
that anyone cares about to some new syntax. The current syntax is not
an emergency.

For that matter, if anybody has any suggestions for a different
syntax, by all means send them in. But please try to look at the
syntaxes that have already been proposed. I'm seeing the same ideas
multiple times, including ideas that are discussed in the design
draft. If you want to help, please take the time to do some research,
and try writing some code with the syntax. Consider particular cases
like functions with type parameters but no non-type parameters.

I hope that makes my position clearer. Thanks.

Ian

[Henry]

I looked at the updated design draft for generics. As much as I crave the extra static type verification and generics in general, it makes me wonder now whether they are worth the extra complexity. The basic usage is fine, but when we get into corner cases, they just turn me off. I would rather choose the current Go without generics. I say we should really take our time with this and not rush into things. Whatever we have in the draft design is far from being complete.