Compiler Rejects Functions Without Visibility (Solidity 0.5.0+): Public Getter or Explicit Accessors?

Answer (to the exact question)

When a struct contains a mapping (or an array) and you need to expose its data, the safest and most flexible approach is to keep the variable internal and write explicit getter functions that can enforce require checks on msg.sender or contract state. A public declaration will generate a getter that returns every non‑mapping, non‑array member but cannot be overridden, guarded, or reshaped.

Why public is limited

• Generated getter is view and external; you cannot add onlyOwner or similar modifiers.
• It omits mapping and array members entirely; callers cannot query those fields directly.
• Its selector is fixed (name() for simple types, name(key) for mappings, name(index) for arrays). Replacing the variable with an internal one requires re‑implementing a matching function to preserve ABI compatibility.

Why internal + manual getters is preferable when you need control

• You can enforce caller identity, time locks, or other business rules.
• You can reshape the return value, e.g., return only a subset of fields or compute derived values.
• You can change the return signature later without breaking the ABI, as long as you keep the function selector stable.

Gas and bytecode considerations

The compiler‑generated getter is compact and incurs only storage reads. A manual getter adds a few extra instructions for the require checks and for packing/unpacking the return data. In most cases the gas difference is modest (<10 % for a simple check) and the bytecode size impact is small. However, if the contract is deployed on a chain with very high deployment costs or you have many such getters, profiling on the target fork is advisable.

Practical steps for your use case

1. Choose internal for the struct and write a function getUser(address user) external view returns (uint balance, uint lastUpdated) (or similar) that includes your access logic.
2. Compile with the exact compiler version and optimizer settings you plan to deploy. Verify that the ABI contains the expected selector and that the function is external.
3. Deploy a test instance on a local fork, call the getter from an authorized and an unauthorized address, and confirm the expected revert.
4. Measure gas for a single call and compare it to the automatic getter if you had used public. Use evm_snapshot and evm_revert to isolate the cost.

Missing diagnostic detail

Could you confirm the compiler version and optimizer settings you will use for deployment? Those details influence whether a public getter can be overridden and affect the exact gas numbers.