Skip to content

Commit a92b98b

Browse files
committed
design: fix a typo in the go/ast type parameters document
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 <[email protected]>
1 parent 652174b commit a92b98b

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

design/47781-parameterized-go-ast.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -94,7 +94,7 @@ For the purpose of this document, I propose the following heuristic:
9494
> We consider all documented invariants plus any additional invariants that are
9595
> assumed in significant amounts of code.
9696
97-
Of these two clauses, (1) is straightforward and hopefully uncontroversial: code that is valid in Go 1.17 must parse to an equivalent AST in Go 1.18. (2) is more subtle: there is no guarantee that the syntax tree of invalid code will not change. After all, use of type parameters is invalid in go1.17. Rather, the only guarantee is that _if a property of existing fields holds for a node type N in all representations of code, invalid or invalid, it should continue to hold_. For example, `ast.Walk` assumes that `ast.IndexExpr.Index` is never nil. This must be preserved if we use `IndexExpr` to represent type instantiation, even for invalid instantiation expressions such as `var l List[]`.
97+
Of these two clauses, (1) is straightforward and hopefully uncontroversial: code that is valid in Go 1.17 must parse to an equivalent AST in Go 1.18. (2) is more subtle: there is no guarantee that the syntax tree of invalid code will not change. After all, use of type parameters is invalid in go1.17. Rather, the only guarantee is that _if a property of existing fields holds for a node type N in all representations of code, valid or invalid, it should continue to hold_. For example, `ast.Walk` assumes that `ast.IndexExpr.Index` is never nil. This must be preserved if we use `IndexExpr` to represent type instantiation, even for invalid instantiation expressions such as `var l List[]`.
9898
9999
The rationale for this heuristic is pragmatic: there is too much code in the wild that makes assumptions about nodes in AST representations; that code should not break.
100100

0 commit comments

Comments
 (0)