a-h
proposal: Allow for primitives & fmt.Stringer in addition to string in templates
Discussion happened previous at #609 but focused on integers. I understand @a-h position on clarity around integers and currency. It seems like in the currency case having a type Currency int64 with a String() string function would allow it to be a valid fmt.Stringer and avoid ambiguity. Personally i'd like to see all primitive types and fmt.Stringer accepted by the template. Since the code is generated you aren't paying the reflection cost each time. strconv already has functions for Bool, Float, Int, etc. If you want to have more control, implement the Stringer interface
Looking at our proposal template I think we can answer some questions straight away:
Backwards compatibility - This change should be completely backwards compatible, the generated code may be slightly different but shouldn't be breaking. Threat model - I imagine in this change we would convert to strings and do the same escaping we already do. Go version - We may introduce generics here in runtime, but that is fine, the oldest supported version has generics. Automatic migration - Not applicable? Compile time vs runtime errors - I believe that we can use generics here which would hopefully provide useful errors. Documentation - We can add to https://templ.guide/syntax-and-usage/expressions Examples - A few examples around primitives and how to implement stringer would be useful (currency is a great example)
There is also the question:
Correctness over time - How can we reduce the risk of defects both now, and in future releases?
But overall, I think that this proposal stands up to our requirements, it is just a case of whether moving from opaque string rendering to transparent (in some cases) is what we want.
I think we can solve @a-h concern of displaying nil to a user for example my not supporting any types that are nillable.
The reason the last one was closed is because we didn't get much engagement or discussion in the issue to form a consensus or even a majority.
Per a short discussion on Discord with @joerdav . It might make sense to use a TemplString() string interface as there can be a difference between how you would logging something and want it displayed in a Templ template. I think the display/nil concern is mitigated as you can either error out in the generated code via an if check, or possibly check and fallback to a TemplNilString() interface if satisfied.
I think that this is a sensible change for templ. At the very least I think allowing all primitives should be implemented. And maybe the type Stringer interface { TemplString() string } interface too?
I think this can be implemented if @a-h is in agreement?