-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
proposal: text/template: add nil literal #57773
Comments
CC @robpike |
There is a difficult technical problem here, perhaps best explained by comparing how constants work in templates and the Go language itself. In Go, there is the notion of an "untyped constant", which is promoted to an actual type only when assigned to a variable. This is a powerful idea and one I think is underappreciated. When building the template library, I tried to reproduce this but it's nigh on impossible as there is no actual type system yet things must immediately go into a data structure upon parsing. Templates can go only as far as the syntax allows: 0 becomes an int, 0.0 becomes a float64, and so on. Often but not always one can adjust the type to for instance promote 0 to float64 or For nil it's harder, because nil can be essentially any non-value type. To put a nil into a data structure, one must know the type it has, but there is no type information or, as with numbers or true/false, any syntax to guide you. There may well be a way to do this, but it would require someone to redesign the whole balance of parser and execution engine, and that's not going to happen. Closing as infeasible. |
@robpike Why not use the type interface{}? That's how I assumed it would work. |
This proposal has been declined as infeasible. |
As far as I can see anything can change type in a template. There is no type checking, so really you can point it to any nil pointer and it would work. This code is valid, but $pl is either string or struct so later test is complex. So it's a slightly weak argument to worry about the type as the templates seem more interpretive than GO compiled I use a simple template function null that just returns nil and it's the same result This solution is better than above as a test can be made to see if the variable is set. You can't easily do this if $pl is a string and then a struct |
It's counterintuitive to initialize variables that will eventually hold a map or slice value with false or an empty string.
For example:
More intuitive:
A nil literal would also enable testing for zero values exactly instead of falsey values more broadly:
I couldn't find a previous proposal for this, open or closed.
The text was updated successfully, but these errors were encountered: