cerc-io/solidity
15
0
Fork 0
mirror of https://github.com/ethereum/solidity synced 2023-10-03 13:03:40 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #6986 from ethereum/docs-implicit-conv

Browse Source 
[DOCS] Clarify implicit conversion
This commit is contained in:
chriseth 2019-06-24 14:14:13 +02:00 committed by GitHub
commit 1231c358c4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
docs/types/conversion.rst
View File

@ -8,25 +8,28 @@ Conversions between Elementary Types
Implicit Conversions Implicit Conversions
-------------------- --------------------
If an operator is applied to different types, the compiler tries to If an operator is applied to different types, the compiler tries to implicitly
implicitly convert one of the operands to the type of the other (the same is convert one of the operands to the type of the other (the same is true for assignments).
true for assignments). In general, an implicit conversion between value-types This means that operations are always performed in the type of one of the operands.
is possible if it In general, an implicit conversion between value-types is possible if it makes
makes sense semantically and no information is lost: ``uint8`` is convertible to sense semantically and no information is lost.
``uint16`` and ``int128`` to ``int256``, but ``int8`` is not convertible to ``uint256``
(because ``uint256`` cannot hold e.g. ``-1``). For example, ``uint8`` is convertible to
``uint16`` and ``int128`` to ``int256``, but ``int8`` is not convertible to ``uint256``,
because ``uint256`` cannot hold values such as ``-1``.
For more details, please consult the sections about the types themselves. For more details, please consult the sections about the types themselves.
Explicit Conversions Explicit Conversions
-------------------- --------------------
If the compiler does not allow implicit conversion but you know what you are If the compiler does not allow implicit conversion but you are confident a conversion will work,
doing, an explicit type conversion is sometimes possible. Note that this may an explicit type conversion is sometimes possible. This may
give you some unexpected behaviour and allows you to bypass some security result in unexpected behaviour and allows you to bypass some security
features of the compiler, so be sure to test that the features of the compiler, so be sure to test that the
result is what you want! Take the following example where you are converting result is what you want and expect!
a negative ``int`` to a ``uint``:
Take the following example that converts a negative ``int`` to a ``uint``:
:: ::
@ -42,7 +45,7 @@ cut off::
uint32 a = 0x12345678; uint32 a = 0x12345678;
uint16 b = uint16(a); // b will be 0x5678 now uint16 b = uint16(a); // b will be 0x5678 now
If an integer is explicitly converted to a larger type, it is padded on the left (i.e. at the higher order end). If an integer is explicitly converted to a larger type, it is padded on the left (i.e., at the higher order end).
The result of the conversion will compare equal to the original integer:: The result of the conversion will compare equal to the original integer::
uint16 a = 0x1234; uint16 a = 0x1234;