In ERC20FlashMint.sol, the NatSpec for _flashFee (line 70) and _flashFeeReceiver (line 81) says the function "can be overloaded" when it should say "can be overridden."
In Solidity, overloading means multiple functions with the same name but different parameter types. Overriding means a child contract redefining a virtual function. Since both _flashFee and _flashFeeReceiver are virtual and meant to be overridden by inheritors, the correct term is "overridden."
The rest of the codebase uses "overridden" consistently (Governor.sol, ERC721.sol, Votes.sol, ERC1967Proxy.sol, etc.). These two spots in ERC20FlashMint are the only ones using "overloaded."
How I found this: I was auditing NatSpec consistency across the token contracts and grepped for terminology patterns. gh search code "can be overloaded" returns only these two hits; "can be overridden" returns 8+ correct usages elsewhere.
Happy to open a PR for this if it's welcome.
In
ERC20FlashMint.sol, the NatSpec for_flashFee(line 70) and_flashFeeReceiver(line 81) says the function "can be overloaded" when it should say "can be overridden."In Solidity, overloading means multiple functions with the same name but different parameter types. Overriding means a child contract redefining a
virtualfunction. Since both_flashFeeand_flashFeeReceiverarevirtualand meant to be overridden by inheritors, the correct term is "overridden."The rest of the codebase uses "overridden" consistently (Governor.sol, ERC721.sol, Votes.sol, ERC1967Proxy.sol, etc.). These two spots in ERC20FlashMint are the only ones using "overloaded."
How I found this: I was auditing NatSpec consistency across the token contracts and grepped for terminology patterns.
gh search code "can be overloaded"returns only these two hits;"can be overridden"returns 8+ correct usages elsewhere.Happy to open a PR for this if it's welcome.