January 18, 2026

What’s new in Solidity 0.6 – samparsky

What’s new in Solidity 0.6 – samparsky

Solidity 0.6 was recently released, bringing a few syntactical changes and non-backward compatible changes.

We would be discussing some of the major changes to Solidity, which includes:

  • Function Overriding
  • Abstract Contracts
  • Try / Catch
  • Receive Ether / Fallback Function split
  • Array Resizing
  • State variable shadowing

In previous Solidity versions, there was no explicit way to know which functions an inheriting contract should override. Solidity 0.6 brings with it an improvement that makes it clear which functions an inheriting contract can override.

An inheriting contract can override its base contract function behavior only if they are marked as virtual. The overriding function must then use the override keyword in the function header as shown below.

pragma solidity ^0.6.0;contract Base

}
contract Middle is Base contract Inherited is Middle

}

With this improvement no more checking OpenZeppelin docs as to which functions can be overridden as the Solidity compiler itself can let you know when an inheriting contract overrides a no `virtual` function.

A new keyword abstract was introduced in Solidity 0.6. It is used to mark contracts that do not implement all its functions.

Contracts are to be marked as abstractwhen at least one of their functions is not implemented. Functions without implementation outside an interface have to be marked virtual. Contracts can also be marked as abstract even though all functions are implemented.

abstract contract Feline contract Cat is Feline, Token 
}

Solidity 0.6 introduces a try/catch statement for handling failed contract call errors. It allows you to react to failed external calls.

A failure in an external contract call can be caught using a try/catch statement, as follows:

pragma solidity ^0.6.0;interface DataFeed contract FeedConsumer  catch Error(string memory /*reason*/)  catch (bytes memory /*lowLevelData*/) 
}
}

Solidity supports different kinds of catch blocks depending on the type of error. If the error was caused by revert("reasonString") or require(false, "reasonString") (or an internal error that causes such an exception), then the catch clause of the type catch Error(string memory reason) will be executed.

To enable a contract to receive Ether, it must implement the receive() function. A contract can have at most one receive function, declared using receive() external payable (without the function keyword) as shown in the example below:

pragma solidity ^0.6.0;// This contract keeps all Ether sent to it with no way
// to get it back.
contract Sink
}

A contract can have at most one fallback function, declared using fallback () external [payable] (without the function keyword). This function cannot have arguments, cannot return anything and must have external visibility. It is executed on a call to the contract if none of the other functions match the given function signature, or if no data was supplied at all and there is no receive Ether function. The fallback function always receives data, but in order to also receive Ether it must be marked payable.

pragma solidity >0.6.1 <0.7.0;contract Test 
uint x;
}
contract TestPayable // This function is called for plain Ether transfers, i.e.
// for every call with empty calldata.
receive() external payable
uint x;
uint y;
}

Access to length of arrays is now always read-only, even for storage arrays. It is no longer possible to resize storage arrays assigning a new value to their length. Use push(), push(value) or pop() instead, or assign a full array,

  • Change uint length = array.push(value) to array.push(value);. The new length can be accessed via array.length.
  • Change array.length++ to array.push() to increase, and use pop() to decrease the length of a storage array.
contract Test }

State variable shadowing is considered as an error. A derived contract can only declare a state variable x, if there is no visible state variable with the same name in any of its bases.

An example is shown below:

contract Test contract TestOverride is Test 

This is an explicit requirement that furthers helps improve reading and understanding a Solidity codebase.

Solidity 0.6 brings with it much needed improvements and explicitness requirements that make reading and understanding a Solidity codebase easier.

Published at Sat, 15 Feb 2020 18:33:52 +0000

Previous Article

$96 Million worth of Bitcoin (BTC) Just Got Wiped at BitMex

Next Article

Myles Garrett’s Racism Claim Doesn’t Add Up for One Big, Cynical Reason

You might be interested in …