Skip to content
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

Closed
rsc opened this issue Aug 23, 2012 · 7 comments
Closed

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

rsc opened this issue Aug 23, 2012 · 7 comments
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented Aug 23, 2012

Feature request more than bug report.
http://golang.org/cl/6485057 has demos
@robpike
Copy link
Contributor

robpike commented Aug 23, 2012

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
Copy link
Contributor

robpike commented Aug 23, 2012

Comment 2:

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

@robpike
Copy link
Contributor

robpike commented Aug 23, 2012

Comment 3:

Status changed to Thinking.

@rsc
Copy link
Contributor Author

rsc commented Aug 24, 2012

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
Copy link
Contributor Author

rsc commented Aug 24, 2012

Comment 5:

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

@rsc
Copy link
Contributor Author

rsc commented Sep 12, 2012

Comment 6:

Labels changed: added go1.1maybe.

@robpike
Copy link
Contributor

robpike commented Sep 24, 2012

Comment 7:

This issue was closed by revision 9050550.

Status changed to Fixed.

@rsc rsc added fixed labels Sep 24, 2012
@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1maybe label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
@rsc rsc unassigned robpike Jun 22, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants