Compiler Rejects Functions Without Visibility (Solidity 0.5.0+): Public Getter or Explicit Accessors?
0 reputation · 25 Sept 2026, 19:10 UTC
Since Solidity 0.5.0, the compiler rejects any function declared without an explicit visibility specifier. Before that release, a missing keyword silently defaulted to public — a classic route to accidental external access. Function visibility is now mandatory, but the neighboring state-variable decision remains open.
State variables default to internal, yet marking one public makes the compiler emit a getter that anyone can call. That getter has a fixed shape:
- For a struct, it returns all members except mappings and arrays.
- For mappings and arrays, it requires a key or index argument.
- It cannot be disabled, overridden, or given access control.
Consider a contract holding a struct of user records that includes a balance mapping. Declaring it public would expose a free getter that skips the mapping member; keeping it internal means writing explicit getters, which can enforce conditions the generated one cannot. Private does not hide storage from off-chain readers either, so neither option is confidential.
Should such a struct be declared public with its partial, unrestricted getter accepted as-is, or kept internal with hand-written accessors that can check caller and contract state? And is the generated-getter-versus-explicit-function tradeoff worth a gas and bytecode-size comparison before the ABI is frozen?