Hugo is contributing a lot to the glory of Go language, so it would be nice to release the burden of maintaining separate fork from Hugo devs since the proposal addresses issues which cab be useful in wider scope.

My first impression of this proposal is that it intends to be an overhaul of the API, to also make the packages more powerful. It sounds more like a v2 module, or even a separate module, instead of a small set of incremental changes we could do to the existing packages.

stateful functions. [...] you could make it a method [...] but it's not very practical

Could you expand on this? I think a method is probably the right solution here for most people.

adding some execution context to methods that support it, [...] allow a custom variant of the built-in and rather opinionated version of IsTrue

The first proposal seems likely to be accepted in some form, and the second had a proposed solution that hasn't been implemented yet. Is there a reason you prefer this larger proposal over those two smaller, incremental proposals?

Granted that neither have advanced recently, but that doesn't mean they are rejected or unlikely to happen. Our efforts here could be focused there.

Doing this also removes some performance bottlenecks.

Has anyone investigated whether we could get any performance gains without touching the API? For example, there are dozens of encoding/json alternatives out there with very different APIs, but in recent versions of Go we simply made internal incremental changes to improve performance by 10-30%. I consider API changes to be the last resort when one wants to improve performance.

Could you expand on this? I think a method is probably the right solution here for most people.

These functions represent what I would call cross cutting concerns (string translation, logging, caching ...). In Go templates, the method API is limited to the "dot" you pass into Execute and then the "dot" you pass on to any nested template definition. In Hugo, we have interfaces such as Page, Image, Site etc., and while I guess it may be possible in the simple case to embed some I18nHelper or something into all of these, I don't see how it would be practical/possible/pretty. You need to consider templates calling other templates that would then need to somehow wrap the original context ... Even I get dizzy thinking about this, then think about Average Joe.

Is there a reason you prefer this larger proposal over those two smaller, incremental proposals?

Two reasons: 1) I'm convinced that looking at this problem as a whole will give an overall much better and more flexible design. I'm not saying my outlined design is fantastic, but it is at least a coherent starting point. 2) These smaller incremental proposals have a tendency to move very slowly to their resolution. Sitting back and watch these slowly fall into place from Go 1.10 to Go 1.20 is not great if you really need them.

As to the specific IsTrue discussion. If I remember correctly, the proposed solution was to make it a template function that could be overridden. In my opinion, these functions/methods are not meant to be called from the templates, so putting them there sounds like a convenience thing, and to me, it sounds much better to define one or more interfaces that would have proper GoDoc etc.

I consider API changes to be the last resort when one wants to improve performance.

"Almost every performance problem can and should be solved by redesigning, rather than optimizing. Optimization techniques should be the absolute last tool(s) you reach for, not the first." - Quote Peter Bourgon on Twitter. I do not agree with everything he says, but this I do.

@bep I took at look at the API you've made in your fork and the documentation seems a little lacking. For example, what does this function do?

It would be helpful if you could provide a full summary of the entire API that you're proposing in this issue, so we don't have to look into the code to try to see what the changes are and what they do.

Thanks.

@bep AFAICS a significant portion of your concerns (with the exception of #28391, which already has an accepted solution, and #20503, which has a good workaround in any case) could be solved if #31107 was implemented to allow "silent" passing of context.Context through to any function that has a context as a first argument.

Would that be a reasonable characterisation? If there are more use cases that you have in mind, it might be good to list them here.

@bep have you considered publishing your forked packges in their own repo?

Attracting users is the best way to prove your point re better design, and convincing the Go team to fix/enhance stdlib APIs is, erm... time consuming :-p

@rogpeppe I think you're missing out on the main topic of this issue: A stricter separation of parsing and execution to allow for stateful functions, which also would get rid of a fairly expensive RLock/RUnlock construct, which wouldn't get any better if you implement #28391 as a template function -- which would mean that every conditional (if, with etc.) would be protected by a mutex. A proposal to do similar with Go's if statement would, I assume, be rejected.

I will try to find time to do better GoDoc of Hugo's fork in the next few days. But the custom code should be between 50-100 lines of Go code in 2 files, so it should be doable to understand it even without.

@networkimprov I have put this into an internal package in Hugo for a reason. Putting it "out there" would 1) Make it harder to get back to 1 source of truth (which this issue is about) and 2) It would add work that I currently do not have time for. But I would welcome it if this proposal could maybe lead to an alternative design that allowed for the template execution to live in a package outside stdlib.