proposal: text/template: allow comments in operands

[phenpessoa]

What version of Go are you using (go version)?

$ 1.16.7

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

N/A

What did you do?

Tried commenting operands.

{{$products := dict 
	"A" ( customslice
		/* Price */
		10
		/* Stock Amount */
		500
	)
}}
{{$products}}

What did you expect to see?

map[A:[10 500]]

What did you see instead?

unexpected "/" in operand

Playground:

https://play.golang.org/p/xDe9j18R3T5

-- Edit
A simpler example:

{{$x := 1 /* x variable */}}
{{$x}}

Playground:
https://play.golang.org/p/XK5h2JBD_8e

[rsc]

/cc @robpike

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[robpike]

This is a perfect example of the camel's nose entering the tent. Actions were deliberately restricted to a single line to keep things simple. Then they were made mulltline because - why? And now the proposal is to break the model again, this time with significant implementation cost. This is not how comments work in the lexer.

I'm not saying this mustn't be done - but I am most definitely not saying it must - I just want to point out how this is a perfect example of how even small innocuous changes lead to further changes and complexity. Reasonable changes lead to ever more changes over time.

The template language was never intended to be a full programming language. it's there to support Go, not replace it.

[phenpessoa]

Hi, Rob!
I see your point. But I don't think allowing multiline actions nor allowing comments inside operands will make the template a real programming language. Nor make it get any close to replacing Go.

Both these changes, in my opinion, are more of a "cosmetic" change (to the front end) and both make for a better UX.

If implementation cost is too significant though, it might not be worth it. And I'm fine with that.
In the end, this is not a proposal to change the template per se, but just a feature that would make life easier for people that deal with the template package. Everything needs to evolve, and I think this applies to the template package as well.

[robpike]

Thanks for replying.

I was thinking about this a lot today. My worry is not with this feature at all, it's the step it takes towards making the actions a full programming language. Their original design - and the design of the whole package - was to provide a way to format data neatly, a glorified printf if you will.

It's actually intended to be simple and a bit clumsy. You already have a programming language - Go - available, and the template language is intended to support it, not replace it. My concern is that pushing towards nice cosmetics and multiline actions will certainly lead to more proposals for more features. I'm expecting next to see requests for control structures and other constructs inside actions.

In order to not encourage further development of the template language, I'd like to keep it as it was, with simple one-line actions that either format some data or provide a piece of a control structure around other template elements. I lost the one-line fight, but I don't want to see any further progress down the full-programming-language road.

It's not what this change does, it's what it suggests.

[phenpessoa]

Thanks for the feedback!

This makes a lot of sense. Little by little the template package is getting closer to a programming language and that is not what this is intended for.
I think this "issue" is coming because of the html template, and not because of the text template. It is becoming more and more popular for web development (hugo is a great example) and this tends to ask for more and more features.

But I can see that accepting every "simple" request, like this one, will eventually lead to a point where the package would be basically rewritten.

At this point, I think it is a matter of carefully picking which changes to be accepted and which ones to be declined.
I can see that down the road people might ask for control structures because now they have multiline and comments. But, should multiline and comments have never been implemented in the first place, or should there be a limit to what else can be implemented?
If the answer is that they should never have been implemented in the first place, I'm happy to close this proposal!

This is without taking into consideration the implementation cost of this proposal. If this is too big and/or requires too many changes to the lexer, it might not even be worth it in the first place for that reason alone.

Thanks again for the response and explanation!

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[rsc]

No change in consensus, so declined.
— rsc for the proposal review group