Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
text/template: allow field/method reference on result of niladic function #3999
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