Go 1.26 makes pointers shorter; absence still needs a meaning
Go 1.26 simplifies initialized pointers. Learn when an absent scalar differs from an explicit zero and why shorter syntax proves no performance gain.
By 
Paul. Languages and frameworks
A missing limit and a limit deliberately set to zero can require different business decisions. Go 1.26 made it easier to construct a pointer holding a scalar value. That convenience is useful when the pointer represents a meaningful distinction between absence and presence. It leaves the distinction itself for the application to define.
Looking back at the week of 4 February 2026, the relevant release arrived on 10 February. The Go release announcement introduced expressions as operands to the built-in new function. This is a language convenience with consequences for readability. Treating it as permission to make every field optional would confuse a construction mechanism with a domain decision.
A value can be present and still be zero
Consider a hypothetical configuration screen where an omitted daily limit means “inherit the organisation setting”. An explicit zero might mean “allow no activity”. If the receiving service collapses both inputs to the integer zero, it loses information before it can apply either rule. A pointer can represent presence: nil for absence, and a non-nil pointer holding zero for the explicit setting.
That example is an illustration of a possible contract, not a claim about an existing product. Another service could reasonably define zero as “unlimited”. The software cannot choose between those meanings by inspecting the pointer type. The people defining the service must agree on the contract and communicate it to every caller.
Presence also needs an end-to-end interpretation. A form might omit an untouched field, an API might accept a value, and storage might record the resulting setting. If one boundary replaces omission with a default too early, the pointer used elsewhere cannot restore the lost intent. Review the path through those boundaries before changing the representation.
What the new expression changes
The Go 1.26 release notes explicitly connect the feature to optional values in serialization. The older new(type) form creates a variable with that type's zero value and returns its pointer. The new new(expression) form uses the expression to specify the initial value. The release announcement illustrates this with new(int64(300)), replacing a temporary variable followed by taking its address.
Both forms produce a pointer. Neither means “absent”. A pointer to a zero-valued integer remains present, which matters when reading a change that replaces a helper or a local variable with a shorter expression. The intended presence state should survive the rewrite. Code review should ask whether the same initial value and type are preserved, rather than simply counting removed lines.
The earlier design discussion belongs to the proposal history. It should not be used to date the shipped feature before the February release. A design conversation can explain motivation; the dated release establishes when this syntax entered the released language. Projects using an earlier language version still need an expression their supported toolchain understands.
Optionality can be the unnecessary part
The strongest objection is that pointers complicate a model which might work perfectly well with ordinary values. Every optional field adds a state that readers and callers must understand. If an absent count and a zero count always cause identical behaviour, carrying both states through the application can create work without preserving useful information.
In that case, start with the business rule. A required scalar may be the clearer choice. If absence matters only while receiving input, an input representation can preserve it until validation resolves the value. The rest of the application need not automatically inherit the same optional shape. This is a design option, not a universal prescription to separate every input type.
There are also contracts for which a single pointer is insufficient. If an update must distinguish “leave unchanged”, “clear the setting”, and “set a value”, the API needs those three intentions represented deliberately. Do not assume that a nullable pointer alone records every distinction made by the transport. Read the decoding contract and specify which states survive it.
Readability and allocation are different questions
A shorter construction can make a value's purpose easier to see beside the surrounding fields. It does not establish that the program allocates on the heap, allocates less, or executes faster. Those are implementation questions involving the compiler and the particular program. The word new is not a benchmark result.
A performance claim would require evidence from the supported toolchain and representative code. No runtime measurements underpin this article. The recommendation is limited to expressing an already justified value more directly. It gives no reason to rewrite working code solely to obtain an assumed speed improvement.
For a bounded adoption, choose a field whose presence rules are already documented. Compare omission and explicit zero through the receiving boundary, then review the resulting behaviour. Keep version compatibility visible in the decision. A syntax modernization that silently raises the minimum language version affects contributors and deployment environments even when the business behaviour stays the same.
When that presence contract is still unclear, custom software development should begin by deciding what the user can express and what the service must retain. Go 1.26 reduces the ceremony once that decision exists. The useful review question remains concrete: does the application preserve the difference its users actually need?