cerc-io/solidity
16
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 #4859 from ethereum/input-output

Browse Source 
Create section that covers input and output function types
This commit is contained in:
chriseth 2018-12-17 17:33:23 +01:00 committed by GitHub
commit bcef78b4ce
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
docs/types.rst
View File

@ -19,6 +19,7 @@ on its type. To handle any unexpected values, you should use the :ref:`revert fu
tuple with a second `bool` value denoting success. tuple with a second `bool` value denoting success.
.. index:: ! value type, ! type;value .. index:: ! value type, ! type;value
.. _value-types:
Value Types Value Types
=========== ===========
@ -728,6 +729,8 @@ Another example that uses external function types::
.. index:: ! type;reference, ! reference type, storage, memory, location, array, struct .. index:: ! type;reference, ! reference type, storage, memory, location, array, struct
.. _reference-types:
Reference Types Reference Types
=============== ===============
@ -761,14 +764,17 @@ non-persistent area where function arguments are stored, and behaves mostly like
depending on the kind of variable, function type, etc., but all complex types must now give an explicit depending on the kind of variable, function type, etc., but all complex types must now give an explicit
data location. data location.
.. _data-location-assignment:
Data location and assignment behaviour
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Data locations are not only relevant for persistency of data, but also for the semantics of assignments: Data locations are not only relevant for persistency of data, but also for the semantics of assignments:
assignments between storage and memory (or from calldata) always create an independent copy.
Assignments from memory to memory only create references. This means that changes to one memory variable * Assignments between ``storage`` and ``memory`` (or from ``calldata``) always create an independent copy.
are also visible in all other memory variables that refer to the same data. * Assignments from ``memory`` to ``memory`` only create references. This means that changes to one memory variable are also visible in all other memory variables that refer to the same data.
Assignments from storage to a local storage variables also only assign a reference. * Assignments from ``storage`` to a local storage variable also only assign a reference.
In contrast, all other assignments to storage always copy. Examples for this case * All other assignments to ``storage`` always copy. Examples for this case are assignments to state variables or to members of local variables of storage struct type, even if the local variable itself is just a reference.
are assignments to state variables or to members of local variables of storage struct type, even
if the local variable itself is just a reference.
:: ::
@ -1120,9 +1126,10 @@ assigning it to a local variable, as in
``campaigns[campaignID].amount = 0``. ``campaigns[campaignID].amount = 0``.
.. index:: !mapping .. index:: !mapping
.. _mapping-types:
Mappings Mapping Types
-------- =============
You declare mapping types with the syntax ``mapping(_KeyType => _ValueType)``. You declare mapping types with the syntax ``mapping(_KeyType => _ValueType)``.
The ``_KeyType`` can be any elementary type. This means it can be any of The ``_KeyType`` can be any elementary type. This means it can be any of