ETHEREUM SMART CONTRACTS DEVELOPMENT

Solidity Fundamentals: Functions

Functions: Part One

In this part we will be focusing on the following topics related Functions;

• Visibility and Getters
• Function Modifiers
• Constant and Immutable State Variables
• Function Parameters and Return Variables
• Pure, View Functions

Visibility and Getters

There are four types of visibility for Solidity functions and state variables (see: Data Location and Assignment Behaviors ): external, public, internal and private. external visibility is not possible for state variables.

external: These types of functions can only be invoked from the outside of a contract and via transactions. It is not possible to call f() external internally. When dealing with large arrays of data, these functions can be highly efficient since the data is not copied from calldata to memory(see: Data Location and Assignment Behaviors ).

public: Public functions can be called from any place — outside of a contract or internally. Getter function is generated automatically for public state variables.

internal: Those functions and state variables can only be called from within the current contract or contracts deriving from it.

private: Private functions and state variables can only be called the contract they are defined in.

Note: Everything that is inside a contract is visible to all observers external to the blockchain. Making something private only prevents other contracts from reading or modifying the information, but it will still be visible to the whole world outside of the blockchain.

Function Modifiers

With the usage of modifiers, we can check a condition prior to executing the function. They are inheritable properties of contracts and may be overridden by derived contracts, but only if they are marked virtual (wait for inheritance chapter in upcoming sections).

Note: We can apply multiple modifiers to functions by placing them in a whitespace-separated list and they are evaluated in the order presented.

Constant and Immutable State Variables

immutable and constant are keywords that can be used on state variables to restrict modifications to their state. The difference is that constant variables can never be changed after compilation, while immutable variables can be set within the constructor. It is also possible to declare constant variables in file level.

Note: The compiler does not reserve a storage slot for these variables, and every occurrence is replaced by the respective value (see: Data Location and Assignment Behaviors ).

Not all types for constants and immutables are implemented at this time. The only supported types are strings (only for constants) and value types.

Function Parameters and Return Variables

Functions can take typed parameters and compare to other languages, Solidity functions also return an arbitrary number of values as output.

function parameter

Parameters are declared the same way as variables.

Note: An external function cannot accept a multi-dimensional array as an input parameter. This functionality is possible if you enable the new ABIEncoderV2 feature by adding pragma experimental ABIEncoderV2; to your source file.

An internal function can accept a multi-dimensional array without enabling the feature.

return variables

Return variables are declared with the same syntax as declaring parameters after the returns keyword and they can be used as any other local variable. Names of return variables can be omitted.

Note: You cannot return some types from non-internal functions, notably multi-dimensional dynamic arrays and structs. If you enable the new ABIEncoderV2 feature by adding pragma experimental ABIEncoderV2; to your source file then more types are available, but mapping types are still limited to inside a single contract and you cannot transfer them.

Pure, View Functions

view: Functions can be declared view in which case they don’t modify the state.

The following statements are considered modifying the state:

1. Writing to state variables.
2. Emitting events.
3. Creating other contracts.
4. Using selfdestruct.
5. Sending Ether via calls.
6. Calling any function not marked view or pure.
7. Using low-level calls.
8. Using inline assembly that contains certain opcodes.

Note: Getter methods are automatically marked view.

pure: Functions can be declared pure when they don’t read from or modify the state.

The following are considered reading from the state:

1. Reading from state variables.
2. Accessing address(this).balance or <address>.balance.
3. Accessing any of the members of block, tx, msg (with the exception of msg.sig and msg.data).
4. Calling any function not marked pure.
5. Using inline assembly that contains certain opcodes.

Next we will continue Functions: Part Two — receive Ether function, fallback function, function overloading and events. Thanks for reading.

References

Contracts - Solidity 0.7.4 documentation

Solidity Fundamentals | Data Location and Assignment Behavior

All Parts in Order

• Layout of a Contract
• Value Types: Part One
• Value Types: Part Two
• Operators
• Reference Types
• Data Location and Assignment Behaviors
• Control Structures
• Error Handling: Assert, Require, Revert and Exceptions
• Functions: Part One
• Functions: Part Two

Feel free to ask any questions.

Stay safe, do good work, and keep in touch!

Ferdi Kurt