text/template: allow field/method reference on result of niladic function

[rsc]

Feature request more than bug report.
http://golang.org/cl/6485057 has demos

[robpike]

Comment 1:

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.

[robpike]

Comment 2:

s/value of the value/value or the value/
Speaking of confusing.

[robpike]

Comment 3:

Status changed to Thinking.

[rsc]

Comment 4:

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

[rsc]

Comment 5:

(Ignore first line of last comment; gmail broke the Summary update by wrapping it.)

[rsc]

Comment 6:

Labels changed: added go1.1maybe.

[robpike]

Comment 7:

This issue was closed by revision 9050550.

Status changed to Fixed.