Why hasn't ast.RangeStmt a Range field?

[T L]

Then how to get the position of the "range" keyword?

[T L]

The same situation is for the "else" in a IfStmt.

[T L]

OK, I just found this: https://github.com/golang/go/issues/13590

I really think this is a defect which should be fixed in Go 2.

Is it possible that to add an "ast.RangePos(rs *astRangeStmt) token.Pos" function to keep Go 1 compatibility?

On Saturday, March 14, 2020 at 7:27:28 AM UTC-4, T L wrote:

[adon...@google.com]

> I really think this is a defect which should be fixed in Go 2.

I agree it's a defect, but it's apparently not a big enough one to justify a breaking change---that's the conclusion of #13590. Can you work back from the position of the range operand, assuming 'range' is followed by a single space? A kludge, I know. It may be possible to add a RangePos method if you can show that the kludge really cannot work, but it's just a different kind of a kludge. This is a question for gri.

Technically it's not a breaking change: the compatibility guarantee permits addition of fields to structs like RangeStmt, because they should always be constructed using named fields. But clearly this argument failed to convince. (There's also the separate question of how we change go/ast as the language evolves. Perhaps we could piggyback this field into one of those changes.) 

(BTW, Ian Lance Taylor argued in a talk (https://www.youtube.com/watch?v=LqKOY_pH8u0) that "Go 2" should not break existing programs. In other words, there may be Go 1.x for large values of x, but no "Go 2" as understood by semantic versioning. It may be possible for new files in a package to use a new dialect, but existing files and libraries should continue to work.)

[T L]

The real situations might be more complex. More specifically,

there might be arbitrary number of comments between tokens.

Handling such cases are error prone.

I have solved this problem by written a 40 lines functions to

find the "else" and "range" token. But I really think it would be

better to have such functions in std packages.

--
You received this message because you are subscribed to the Google Groups "golang-tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-tools...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-tools/a5ab1249-41a2-49e6-8fba-ea2200600aa1%40googlegroups.com.