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
text/template: allow field/method reference on result of niladic function #3999
Labels
Milestone
Comments
A function is defined to be an identifier. The feature requested expands this definition to require function evaluation. This idea was tried a while back and rejected because it is too confusing: is f a function value of the value of evaluating f? Many ambiguities result and the change, which was already in, was pulled. A syntax that resolves the ambiguity would help; until then variables are needed: $v=f will, by definition, call f since f is a pipeline. For the back burner. Labels changed: added priority-someday, packagechange, removed priority-triage. |
niladic function I have no problem with this being on the back burner, but a clarification: Auto-invocation of function values came up in the context of evaluations that returned functions, such as a function-typed struct field or a method call returning a function. The ambiguity happened because sometimes you do want the func value, and auto-invocation was making that impossible to get. However, predefined functions and also method references have always been auto-invoked, because there is no uninvoked form to preserve. I think I overgeneralized and put too much in the test case. Regardless of what the test case says, let's make this issue about the following. http://golang.org/pkg/text/template/#Arguments describes what an argument is. Rephrased, I believe it defines the current behavior as: - .Field, referring to a field of the current cursor - .Method, referring to a niladic method of the current cursor - $x, referring to the variable x - arg.Field or arg.Method (niladic), where arg is one of the argument forms in this list up to and including this entry - ideal constants such as 0 or "hello" - 'fun', referring to a niladic function installed under the name 'fun'. The suggestion is to generalize and simplify the arg.Field/arg.Method line to: - arg.Field or arg.Method (niladic), where arg is any argument This generalization has no effect on ideal constants since they have no fields or methods, but it would allow fun.Field1 the same way that $x.Field1 and .Method.Field1 are already allowed. The generalization would, if parenthesized expressions were added, also allow (x | y).Field1, since a parenthesized expression would become a valid kind of argument. Russ |
This issue was closed by revision 9050550. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: