-
Notifications
You must be signed in to change notification settings - Fork 18.1k
text/template: index/element switched for iter.Seq2 in range #73282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Existing implementation conforms to the specification
|
@qiulaidongfeng this issue is about the Some additional arguments to my initial post:
|
See https://go.dev/doc/go1.24#minor_library_changes
not to support other new semantics. By the way, it has been released by go1.24, so, according to https://go.dev/doc/go1compat, for backward compatibility, we should not change. |
I don't think this is something we can change at this point. Plus, while it convention to return (index, value) when working with slices, that may not always be true when working with iterators in general. For example, fallible iterators may choose to return (value, error), and it would be decidedly less useful if the single value iteration returned just the errors. |
Of course you can change this. You may not want to change this. But if you ask 100 developers about this, 99 will say that this is a bug. @dmitshur not sure what this "closed as not planned" comes from. In Hugo, I suspect the biggest consumer/producer of Go templates in the wild, we have a "soft fork" of the Go template execution code, and I can certainly maintain this patch if needed (and I really need it), but that means that there will eventually be confusion, and I'm pretty sure the issues/questions will end up on this issue tracker and not mine. |
Since it's not already mentioned here, the proposal for this was #66107, and the accepted plan there was:
The current implementation seems to match the plan in the accepted proposal, right? It's not possible to change the current behavior without also breaking programs that have been written targetting the Go 1.24 behavior. If it should be changed anyway, one possible path is to change it in a future version of Go by gating it on the go directive. That would need a new proposal rather than a regular issue. I'm not the owner of this package and I haven't looked closely at the details and previous discussion, but at a glance it looks like both directions (staying closer to Go semantics vs staying closer to text/template semantics) have trade-offs, such that making a change would help in some ways and make other things worse. It's worth opening a proposal if there is information that hasn't already been considered during discussion of proposal #66107 or in this issue. |
@dmitshur I have read the proposal several times, and 1. The proposal does not say anything about what the "dot" should be for Oh, well, I understand that I'm late to the party here and that this is a tough sell, but I will repeat and say that it's incredibly unfortunate that you have created new range syntax that's not compatible with how it works with slices and maps. |
This might just need to be labeled as Unfortunate. |
Uh oh!
There was an error while loading. Please reload this page.
Go version
go1.24.2 darwin/arm64
Output of
go env
in your module/workspace:What did you do?
What did you see happen?
What did you expect to see?
The text was updated successfully, but these errors were encountered: