aboutsummaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/abi-spec.rst13
-rw-r--r--docs/types.rst61
2 files changed, 43 insertions, 31 deletions
diff --git a/docs/abi-spec.rst b/docs/abi-spec.rst
index 8a5e2f5c..4e7c88d0 100644
--- a/docs/abi-spec.rst
+++ b/docs/abi-spec.rst
@@ -78,13 +78,14 @@ Types can be combined to a tuple by enclosing them inside parentheses, separated
It is possible to form tuples of tuples, arrays of tuples and so on. It is also possible to form zero-tuples (where ``n == 0``).
-.. note::
- Solidity supports all the types presented above with the same names with the exception of tuples. The ABI tuple type is utilised for encoding Solidity ``structs``.
-
Mapping Solidity to ABI types
-----------------------------
-The following table shows on the left column Solidity types that are not part of the ABI,
-and on the right column the ABI type that they map to.
+
+Solidity supports all the types presented above with the same names with the
+exception of tuples. On the other hand, some Solidity types are not supported
+by the ABI. The following table shows on the left column Solidity types that
+are not part of the ABI, and on the right column the ABI types that represent
+them.
+-------------------------------+-----------------------------------------------------------------------------+
| Solidity | ABI |
@@ -98,6 +99,8 @@ and on the right column the ABI type that they map to.
| |For example, an ``enum`` of 255 values or less is mapped to ``uint8`` and |
| |an ``enum`` of 256 values is mapped to ``uint16``. |
+-------------------------------+-----------------------------------------------------------------------------+
+|:ref:`struct<structs>` |``tuple`` |
++-------------------------------+-----------------------------------------------------------------------------+
Formal Specification of the Encoding
====================================
diff --git a/docs/types.rst b/docs/types.rst
index 1cbbb1be..49a0506a 100644
--- a/docs/types.rst
+++ b/docs/types.rst
@@ -276,15 +276,19 @@ Contract Types
--------------
Every :ref:`contract<contracts>` defines its own type.
-You can implicitly convert contracts to contracts they inherit from,
-and explicitly convert them to and from the ``address`` type, if they have no
-payable fallback functions, or to and from the ``address payable`` type, if they do
-have payable fallback functions.
+You can implicitly convert contracts to contracts they inherit from.
+Contracts can be explicitly converted to and from all other contract types
+and the ``address`` type.
+
+Explicit conversion to and from the ``address payable`` type
+is only possible if the contract type has a payable fallback function.
+The conversion is still performed using ``address(x)`` and not
+using ``address payable(x)``. You can find more information in the section about
+the :ref:`address type<address>`.
.. note::
- Starting with version 0.5.0 contracts do not derive from the address type,
- but can still be explicitly converted to ``address``, resp. to ``address payable``,
- if they have a payable fallback function.
+ Before version 0.5.0, contracts directly derived from the address type
+ and there was no distinction between ``address`` and ``address payable``.
If you declare a local variable of contract type (`MyContract c`), you can call
functions on that contract. Take care to assign it from somewhere that is the
@@ -307,25 +311,29 @@ including public state variables.
Fixed-size byte arrays
----------------------
-``bytes1``, ``bytes2``, ``bytes3``, ..., ``bytes32``. ``byte`` is an alias for ``bytes1``.
+The value types ``bytes1``, ``bytes2``, ``bytes3``, ..., ``bytes32``
+hold a sequence of bytes from one to up to 32.
+``byte`` is an alias for ``bytes1``.
Operators:
* Comparisons: ``<=``, ``<``, ``==``, ``!=``, ``>=``, ``>`` (evaluate to ``bool``)
-* Bit operators: ``&``, ``|``, ``^`` (bitwise exclusive or), ``~`` (bitwise negation), ``<<`` (left shift), ``>>`` (right shift)
+* Bit operators: ``&``, ``|``, ``^`` (bitwise exclusive or), ``~`` (bitwise negation)
+* Shift operators: ``<<`` (left shift), ``>>`` (right shift)
* Index access: If ``x`` is of type ``bytesI``, then ``x[k]`` for ``0 <= k < I`` returns the ``k`` th byte (read-only).
-The shifting operator works with any integer type as right operand (but will
-return the type of the left operand), which denotes the number of bits to shift by.
-Shifting by a negative amount will cause a runtime exception.
+The shifting operator works with any integer type as right operand (but
+returns the type of the left operand), which denotes the number of bits to shift by.
+Shifting by a negative amount causes a runtime exception.
Members:
* ``.length`` yields the fixed length of the byte array (read-only).
.. note::
- It is possible to use an array of bytes as ``byte[]``, but it is wasting a lot of space, 31 bytes every element,
- to be exact, when passing in calls. It is better to use ``bytes``.
+ The type ``byte[]`` is an array of bytes, but due to padding rules, it wastes
+ 31 bytes of space for each element (except in storage). It is better to use the ``bytes``
+ type instead.
Dynamically-sized byte array
----------------------------
@@ -343,7 +351,7 @@ Address Literals
----------------
Hexadecimal literals that pass the address checksum test, for example
-``0xdCad3a6d3569DF655070DEd06cb7A1b2Ccd1D3AF`` are of ``address`` type.
+``0xdCad3a6d3569DF655070DEd06cb7A1b2Ccd1D3AF`` are of ``address payable`` type.
Hexadecimal literals that are between 39 and 41 digits
long and do not pass the checksum test produce
a warning and are treated as regular rational number literals.
@@ -371,10 +379,11 @@ Examples include ``2e10``, ``-2e10``, ``2e-10``, ``2.5e1``.
Underscores can be used to separate the digits of a numeric literal to aid readability.
For example, decimal ``123_000``, hexadecimal ``0x2eff_abde``, scientific decimal notation ``1_2e345_678`` are all valid.
Underscores are only allowed between two digits and only one consecutive underscore is allowed.
-There is no additional semantic meaning added to a number literal containing underscores.
+There is no additional semantic meaning added to a number literal containing underscores,
+the underscores are ignored.
Number literal expressions retain arbitrary precision until they are converted to a non-literal type (i.e. by
-using them together with a non-literal expression).
+using them together with a non-literal expression or by explicit conversion).
This means that computations do not overflow and divisions do not truncate
in number literal expressions.
@@ -396,14 +405,15 @@ a non-rational number).
belong to the same number literal type for the rational number three.
.. warning::
- Division on integer literals used to truncate in earlier versions, but it will now convert into a rational number, i.e. ``5 / 2`` is not equal to ``2``, but to ``2.5``.
+ Division on integer literals used to truncate in Solidity prior to version 0.4.0, but it now converts into a rational number, i.e. ``5 / 2`` is not equal to ``2``, but to ``2.5``.
.. note::
Number literal expressions are converted into a non-literal type as soon as they are used with non-literal
- expressions. Even though we know that the value of the
- expression assigned to ``b`` in the following example evaluates to
- an integer, but the partial expression ``2.5 + a`` does not type check so the code
- does not compile
+ expressions. Disregarding types, the value of the expression assigned to ``b``
+ below evaluates to an integer. Because ``a`` is of type ``uint128``, the
+ expression ``2.5 + a`` has to have a proper type, though. Since there is no common type
+ for the type of ``2.5`` and ``uint128``, the Solidity compiler does not accept
+ this code.
::
@@ -820,13 +830,12 @@ Members
^^^^^^^
**length**:
- Arrays have a ``length`` member to hold their number of elements.
- Dynamic arrays can be resized in storage (not in memory) by changing the
- ``.length`` member. This does not happen automatically when attempting to access elements outside the current length. The size of memory arrays is fixed (but dynamic, i.e. it can depend on runtime parameters) once they are created.
+ Arrays have a ``length`` member to read their number of elements.
+ Dynamically-sized arrays (only available for storage) have a read-write ``length`` member to resize the array. Increasing the length adds uninitialized elements to the array, this has *O(1)* complexity. Reducing the length performs :ref:``delete`` on each removed element and has *O(n)* complexity where *n* is the number of elements being deleted. Please note that calling ``length--`` on an empty array will set the length of the array to 2^256-1 due to ``uint256`` underflow wrapping.
**push**:
Dynamic storage arrays and ``bytes`` (not ``string``) have a member function called ``push`` that can be used to append an element at the end of the array. The function returns the new length.
**pop**:
- Dynamic storage arrays and ``bytes`` (not ``string``) have a member function called ``pop`` that can be used to remove an element from the end of the array.
+ Dynamic storage arrays and ``bytes`` (not ``string``) have a member function called ``pop`` that can be used to remove an element from the end of the array. This will also implicitly call :ref:``delete`` on the removed element.
.. warning::
It is not yet possible to use arrays of arrays in external functions.