go/ast, go/token: additions to support type parameters #47781
This proposal formally introduces the changes we’ve made to support parameterized functions and types in the
There will be a separate issue for
We’ve gotten some experience with these new APIs over the last few months by using them in
Any feedback is appreciated.
The text was updated successfully, but these errors were encountered:
Thanks for the proposal.
Typo: "invalid or invalid" -> "valid or invalid"?
I think the general representation of optional arguments/parameter is ok.
Perhaps a better name can be found for MultiIndexExpr: BracketedExpr? (I do not think of type parameters or instantiations as "indices")
But, I don't quite understand why suppositions about the completeness of a set of node types is a concern in the stdlib but the same is not a concern about token: The dev.typeparams commit 7c5d7a4 introduced token.TILDE. Why does the same concern not hold there? I think that one way to handle these issues is documentation: we could state that for go/* stdlib libraries, all exported sets of constants and types can be extended to facilitate language changes: do not assume switches handle all (possibly future) cases.
Could you post a link to the issue for the type proposal here when you are ready?
invalid or invalid -> valid or invalid, as pointed out in golang/go#47781 (comment) (thanks) Change-Id: I203a06a3280bb6a20ac87f78ddf49990b1812331 Reviewed-on: https://go-review.googlesource.com/c/proposal/+/343549 Reviewed-by: Robert Findley <firstname.lastname@example.org>
@scott-cotton thank you for the feedback.
I think an advantage of MultiIndexExpr is similarity with IndexExpr. If we could start over these would be the same node, but since we can't it's important to keep them associated.
You're right that we should extend the same concern to TILDE. I was more concerned about node completeness because I was already aware of places in the x/tools codebase that would panic when encountering an unknown node.
One additional argument for adding a new node is that the panic exists to be sure your type switch covers all syntax. In this context, it would actually be unhelpful to hide the change by packing the new syntax into existing nodes. Perhaps that's overly optimistic.
Yes, will do.
@mdempsky that is the rationale. If we put
It wasn't an obvious choice though.
I'm slightly surprised by the choice of TParams as a name. TypeParams is just slightly longer, and much clearer. I also might mistake TParams for Params or vice versa when quickly reading or reviewing code.
I agree with the decision to go with
Continuing on the point above: this is how I write my type switches in general, including those using
If the addition was made to an existing type, the strong and clear signal via a default case panic would not be there, and I might not notice that my tool actually needs changes to support new or changed node struct fields in existing types.
Thanks for the feedback. I don't feel the same way, but I've been staring at this for a while. With TParams (and TArgs), I've grown accustomed to seeing 'T' as a modifier. With that said, we already have the TypeParam type in go/types, and you are right that TypeParams is not significantly more verbose. We can consider changing the naming convention, but of course if we decide to switch we should apply this change to go/types as well.
Yes, I was concerned at first but have come around to adding a new node as the clear best option. With something like #47783 I don't think it will be a large burden on tool authors to update their code to avoid the panic, especially since many tools will want to have explicit support for type parameters anyway.
@griesemer and I just discussed, and here is our current thinking:
As discussed in the ast proposal (#47781), there's not really a strong reason to avoid spelling out 'Type'. Change-Id: I0ba1bf03b112ea60509a78a89a050a302779d9d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/348375 Trust: Robert Findley <email@example.com> Run-TryBot: Robert Findley <firstname.lastname@example.org> Reviewed-by: Robert Griesemer <email@example.com> TryBot-Result: Go Bot <firstname.lastname@example.org>
As discussed in #47781, IndexListExpr is one character shorter and has the advantage of being next to IndexExpr in documentation. Updates #47781 Change-Id: I709d5c1a79b4f9aebcd6445e4ab0cd6dae45bab7 Reviewed-on: https://go-review.googlesource.com/c/go/+/348609 Trust: Robert Findley <email@example.com> Run-TryBot: Robert Findley <firstname.lastname@example.org> Reviewed-by: Robert Griesemer <email@example.com> TryBot-Result: Go Bot <firstname.lastname@example.org>
Following discussion in golang/go#47781, MultiIndexExpr was renamed to IndexListExpr. Change-Id: Ib8b0d138265d34b5764f5684a12c560838718ae2 Reviewed-on: https://go-review.googlesource.com/c/proposal/+/348382 Reviewed-by: Robert Griesemer <email@example.com>
Allows cgo to work with generics. Updates #47781. Change-Id: Id1a5d1a0a8193c5b157e3e671b1490d687d10384 Reviewed-on: https://go-review.googlesource.com/c/go/+/353882 Trust: Matthew Dempsky <firstname.lastname@example.org> Run-TryBot: Matthew Dempsky <email@example.com> TryBot-Result: Go Bot <firstname.lastname@example.org> Reviewed-by: Ian Lance Taylor <email@example.com>