Update Of Solidity Language: Function Visibility Issues
The Ethereum project is famous and popular in the crypto ecosystem for several reasons. First, it proposes a flexible and convenient way to develop new projects. Most of crypto ICOs are implemented on the Ethereum blockchain. Second, it has a solid background for the Ethereum Virtual Machine and languages addressing it. In general, Ethereum is independently developed software using a programming language called Solidity designed to target its specific virtual machine.
As any other software, solutions within the Ethereum system require upgrades. It is especially important for the Solidity language, as it still hasn’t reached the version 1. The latest update changes the current version number to 0.5.0. This index may be considered as a milestone, so let’s pay attention and examine the update in detail.
General information on the update
All details on the update can be found in several sources. Let’s consider two of them. The first one is the Solidity changelog page at GitHub. It does not contain explanations on each change. However, the list is the most complete, it shows changes starting from July 2015, and includes the following categories:
- Breaking changes;
- Necessary code updates;
- Language features;
- Compiler features;
- Fixed bugs.
Another source is the Solidity manual page provided by the “Read the Docs” website. It explains the most important changes and contains examples and the code. It holds the following categories:
- Semantic changes;
- Semantic and syntax changes;
- Explicitness requirements;
- Deprecation section;
- Issues of contracts interoperability.
Here, we will examine only one important change.
The first change explained in the log is about functions visibility. Each function inside of a smart contract is visible for other on-chain functions in different ways — and it is not about the real visibility for developers or external observers. Any blockchain holder will see all functions and their details. It’s rather about the ability to interact with a function.
Let’s consider a contract with a function called function_name(). There are four types of visibility: external, public, internal, and private. They may be applied both to functions and state variables. The only restriction is that state variables can’t be external. Hereafter, we will talk about functions visibility.
The simplest type of functions has the “Internal” visibility. It means that only other contract’s functions can address this one. Also, if our contract_1 becomes a raw model for inherited contract_2, this function will be copied as it is.
Functions defined as “Private” have the same properties as “Internal” ones, but they will not be copied to the inheriting contract. This type of functions belongs exclusively to the contract that holds them.
Functions defined as “Public” have an extended visibility compared to the Internal ones. In general, the list of contract’s functions available from outside of the contract is called “interface”. It represents the means for contracts interaction. External contracts can call for the “Public” functions execution as well as the hosting contract by itself. The hosting contract requires no special syntax to call the function.
Functions defined as “External” are available for all contracts on blockchain with some peculiarities. “External” functions can be addressed by all of contracts in a similar syntax. It means that hosting contract can’t just call a function by its name. It must use the this.function_name() syntax. “External” functions are similar to “Public” ones but some issues related to the data processing efficiency require using them.
Visibility overall changes
In the previous Solidity version, any function created without visibility specification was automatically assigned “Public”. This has changed with the 0.5.0 update. Explicit function visibility is now mandatory. All functions and interfaces must have a specified visibility definition before being published on blockchain.
This doesn’t mean that previously compiled contracts will be abandoned. According to the developers, there will be no problems with interacting with contracts that already exist on-chain.
The development process brings many interesting solutions, options and proposals. Examining the changelog, we can find some interesting tendencies and opinions in developers’ decisions. However, their volume is so big that, unfortunately, we can’t cover them all at once. In our next article, we will examine more interesting changes in Solidity.