Solidity 0.5.0 - what's new for us

Update: 11/13/2018 release was released , here is a detailed description of the changes. The article tells about the status of this version in May (five months before the release).

I want to talk about the changes in the Solidity language, which are expected in version 0.5.0. Immediately, I note that I will confine myself only to the language — its grammar and semantics.

There is no imputed text on this topic even in English, but recently a project appeared in the Solidity repository.
On it you can track the progress of preparation of version 0.5.0.

Disclaimer: the article describes the current state of the project, a lot can be changed for release. Exact information can be obtained from the official changelog'a .

Final ban on obsolete designs

Solidity has accumulated quite a lot of outdated constructions that I would like to remove from the language, but this still cannot be done due to backward compatibility. This category changes:

• Rejecting throw in favor of revert() / assert(...) / require(...) . The transaction rollback mechanism is different from the exception mechanism, and I want to emphasize this difference at the language level.
• Refusal from var , which, taking into account the rules of type inference, easily leads to errors, for example
  for(var i = 0; i < 100500; i++) { ... //
  Additionally, discuss what to replace designs like
  var (z, y, z) = foo();
  and how more elegant to skip unnecessary values .
• Forbidden to use constant for functions - everywhere should be view or pure.
• Built gasleft() instead of msg.gas . So it is clear that this is not some kind of constant, but the remaining amount of gas. Yes, gasleft() can be overridden.
• block.blockhash to blockhash . It is logical, because the blockhash current block is not available ( block.blockhash(block.number) == 0 ).
• Forbidden to mix hexadecimal constants and time / ether multipliers. In fact, it is not entirely clear what 0xaf days .
• sha3 suicide / sha3 in inline assembly.
• The rejection of the unary plus, because it does not have any special role and can participate in silly errors (like x=+1; instead of x+=1; ).
• It is planned to abandon the years multiplier, because now it is defined as 365 days , and this is not very closely related to the usual calendar. It seems to me a controversial decision - it would seem, as long as you can limit yourself to a warning.

Stricter syntax

In Solidity, very different constructs have a similar syntax. This makes it difficult to read the code, but it even more spoils the life of developers of tools for working with source codes (this applies to the compiler as well). It's nice to see that work is being done in this direction too.

• Mandatory emit keyword when generating events .
  Creating an event was not syntactically different from calling a function (and creating a structure). This problem was especially vividly manifested in the ERC20 standard, in which there is a function and an event with the same “signature”.
• New syntax for constructors :
  constructor(<args>) public { ...
  With the release of 0.5.0, this will be the only option - functions whose names coincide with the contract are prohibited.
  This change solves the problem of renaming files when the designer suddenly turns into a normal function and can be called repeatedly or not called at all.
  This decision looks more reasonable if we remember that the constructor can only be public or internal , cannot be view or pure , cannot have return values, i.e. is a special entity.
  It is curious that, at the same time, an issue was opened with a proposal to allow functions of the same name with a contract of 0.6.0.
• Changing the visibility rules for local variables - from those accepted in Javascript on C99 / C ++.
  My favorite. I can't do anything with myself, every time I am glad when I show how the code is compiled
  

    x = 1; revert(); uint x; }``` 

• Forced inclusion of strict mode for the assembler. It is still available with the --strict-assembly compiler option. It has limited stack manipulation and inaccessible labels and transitions - instead of them it is proposed to use more familiar control structures like for or switch .
• Forbidden to use addresses without a check-sum or incorrect length (different from 20 bytes). Not a bad idea, although it will cause difficulties with unaccustomed - you will have to urgently learn to write addresses with a check-sum, and instead of the usual 0x0 use address(0) .
• Forbidden to declare empty structures ( struct A {} ). Not really wanted, but before the grammar is allowed.

Visibility Modifiers and ABI

With visibility modifiers was an easy mess, largely due to the presence of default values. There are a lot of minor edits that should make the language more stringent, removing this confusion.
And since these modifiers fall into the ABI contract, the changes affected him too.

• All functions in the interfaces must be explicitly marked as external .
  Unfortunately, it is impossible to override such a function as public in some versions of the compiler - an error will occur (for example, in 0.4.21). This has become possible since version 0.4.22.
  They also promise to allow the implementation of external view functions using public variables.
• Visibility modifiers have become mandatory for functions .
  This change has been waiting for its time. Issue on githabe created immediately after the first Hack Parity.
  An additional limitation - the fallback can only be external .

Functions with an arbitrary number of arguments and data packing

In Solidity, there are several functions that take any number of arguments, glue them together into one binary sausage and continue to work with it. In this process, many subtleties and unobvious moments, and now decided to deal with them.

• New abi global object and its methods
  encode , encodePacked , encodeWithSelector and encodeWithSignature , allowing you to control the assembly of data for a call or hash.
  It is proposed to collect arguments for keccak256 / sha256 / ripemd160 and call / delegatecall with their help. It is planned to change the syntax of these commands so that they could not take an argument list of arbitrary length.
• The change in auto-typing for constants in constructions with dense packing of arguments: in constructions like keccak256(1) it is now not the least sufficient type ( uint8 ), but uint256 . If this behavior does not suit you, you will have to use explicit type keccak256(uint8(1)) ).
  This change seems to be logical next to the rejection of var and the high (albeit finite ) accuracy of computing constant expressions.
• Changing array packing rules. It all started with the problem of multi-purse wallets that could not execute transaction contracts that were trying to protect themselves from a short address attack. Apparently, the current behavior was considered rather unobvious, or perhaps it was the preparation for the introduction of the check of the msg.data length at the EVM level.

Improving the "work with memory"

In quotes, because it basically is about "unexpected" access to storage without using assembly.

• Banning non-initialized references to storage, which actually pointed to the beginning of storage, and therefore overlapped with other state variables.
• It may be forbidden to work directly with <array>.length .
  Manually changing the array length is a fairly low-level operation. Its main advantage is gas savings with small changes in the length of the array. But this syntax allows you to randomly (or intentionally) create an array of inadequate size, which can lead to an overlap attack. To delete array for a long time, there is delete , for reducing the size, it is proposed to use pop() , in addition to this, operations like truncate() and extend() are discussed. Well, there is still an assembly, if you really need to.

Out of doubtful

In any barrel of honey will have its own fly in the ointment.

• Add a whole bunch of keywords for all occasions. Some of them look threatening, but so far nothing is clear. Honestly, I hoped to see revert , assert and require in this list, but from the grammar point of view they remain just functions (and they can be overridden).

Not about the language

There are several very important changes that do not directly affect the language, but they will greatly affect the code of new contracts.

• Finally, numbers with a fractional part will appear. It seems everyone used to do without them, and now we will learn to use them correctly .
• At the EVM level, protection against a short address attack will be added. It would seem a trifle, but it is nice that you don’t need to think about it any more (and in general know about this problem). Maybe it will be even more stringent , but there are difficulties.

Any conclusions

Although the release date is still unknown, many innovations can already be touched.
They are enabled using
pragma experimental "v0.5.0";
and
pragma experimental "ABIEncoderV2";
The compiler, of course, gives a warning.

Overall, 0.5.0 is perceived positively. They will remove something that cannot be eliminated due to backward compatibility, they will tightly fix a couple of slippery topics and make several useful changes. Then we'll wait for refactoring of inheritance , and there, maybe, Vyper will arrive in time.