I looked at the updated design draft <https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md> 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.
On Friday, June 19, 2020 at 8:22:30 AM UTC+7 Ian Lance Taylor wrote: > On Thu, Jun 18, 2020 at 4:12 PM Brian Hatfield <bmhat...@gmail.com> wrote: > > > > 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? > > > 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 > -- 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/4794ba89-e329-4875-a971-ae66d92a8bb6n%40googlegroups.com.
