cerc-io/solidity
11
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

Update version pragma in all documentation examples

Browse Source
This commit is contained in:
Alex Beregszaszi
2018-09-25 19:03:25 +01:00
parent c9f468b717
commit 3ca00c73f9
14 changed files with 88 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/contracts.rst
+25 -24
View File
@@ -42,7 +42,7 @@ This means that cyclic creation dependencies are impossible.
::
pragma solidity ^0.4.22;
pragma solidity >=0.4.22 <0.6.0;
contract OwnedToken {
// TokenCreator is a contract type that is defined below.
@@ -173,7 +173,7 @@ return parameter list for functions.
::
pragma solidity ^0.4.16;
pragma solidity >=0.4.16 <0.6.0;
contract C {
function f(uint a) private pure returns (uint b) { return a + 1; }
@@ -187,7 +187,7 @@ In the following example, ``D``, can call ``c.getData()`` to retrieve the value
::
pragma solidity ^0.4.0;
pragma solidity >=0.4.0 <0.6.0;
contract C {
uint private data;
@@ -231,7 +231,7 @@ when they are declared.
::
pragma solidity ^0.4.0;
pragma solidity >=0.4.0 <0.6.0;
contract C {
uint public data = 42;
@@ -251,7 +251,7 @@ it evaluates to a state variable. If it is accessed externally
::
pragma solidity ^0.4.0;
pragma solidity >=0.4.0 <0.6.0;
contract C {
uint public data;
@@ -270,7 +270,8 @@ to write a function, for example:
::
pragma solidity ^0.4.0;
pragma solidity >=0.4.0 <0.6.0;
contract arrayExample {
// public state variable
uint[] public myArray;
@@ -295,7 +296,7 @@ The next example is more complex:
::
pragma solidity ^0.4.0;
pragma solidity >=0.4.0 <0.6.0;
contract Complex {
struct Data {
@@ -456,7 +457,7 @@ value types and strings.
::
pragma solidity ^0.4.0;
pragma solidity >=0.4.0 <0.6.0;
contract C {
uint constant x = 32**22 + 8;
@@ -683,7 +684,7 @@ The following example shows overloading of the function
::
pragma solidity ^0.4.16;
pragma solidity >=0.4.16 <0.6.0;
contract A {
function f(uint _in) public pure returns (uint out) {
@@ -701,7 +702,7 @@ externally visible functions differ by their Solidity types but not by their ext
::
pragma solidity ^0.4.16;
pragma solidity >=0.4.16 <0.6.0;
// This will not compile
contract A {
@@ -734,7 +735,7 @@ candidate, resolution fails.
::
pragma solidity ^0.4.16;
pragma solidity >=0.4.16 <0.6.0;
contract A {
function f(uint8 _in) public pure returns (uint8 out) {
@@ -794,7 +795,7 @@ All non-indexed arguments will be :ref:`ABI-encoded <ABI>` into the data part of
::
pragma solidity ^0.4.21;
pragma solidity >=0.4.21 <0.6.0;
contract ClientReceipt {
event Deposit(
@@ -851,7 +852,7 @@ as topics. The event call above can be performed in the same way as
::
pragma solidity ^0.4.10;
pragma solidity >=0.4.10 <0.6.0;
contract C {
function f() public payable {
@@ -971,7 +972,7 @@ Note that above, we call ``mortal.kill()`` to "forward" the
destruction request. The way this is done is problematic, as
seen in the following example::
pragma solidity ^0.4.22;
pragma solidity >=0.4.22 <0.6.0;
contract owned {
constructor() public { owner = msg.sender; }
@@ -1000,7 +1001,7 @@ derived override, but this function will bypass
``Base1.kill``, basically because it does not even know about
``Base1``. The way around this is to use ``super``::
pragma solidity ^0.4.22;
pragma solidity >=0.4.22 <0.6.0;
contract owned {
constructor() public { owner = msg.sender; }
@@ -1089,7 +1090,7 @@ The constructors of all the base contracts will be called following the
linearization rules explained below. If the base constructors have arguments,
derived contracts need to specify all of them. This can be done in two ways::
pragma solidity ^0.4.22;
pragma solidity >=0.4.22 <0.6.0;
contract Base {
uint x;
@@ -1148,7 +1149,7 @@ error "Linearization of inheritance graph impossible".
::
pragma solidity ^0.4.0;
pragma solidity >=0.4.0 <0.6.0;
contract X {}
contract A is X {}
@@ -1179,7 +1180,7 @@ Abstract Contracts
Contracts are marked as abstract when at least one of their functions lacks an implementation as in the following example (note that the function declaration header is terminated by ``;``)::
pragma solidity ^0.4.0;
pragma solidity >=0.4.0 <0.6.0;
contract Feline {
function utterance() public returns (bytes32);
@@ -1187,7 +1188,7 @@ Contracts are marked as abstract when at least one of their functions lacks an i
Such contracts cannot be compiled (even if they contain implemented functions alongside non-implemented functions), but they can be used as base contracts::
pragma solidity ^0.4.0;
pragma solidity >=0.4.0 <0.6.0;
contract Feline {
function utterance() public returns (bytes32);
@@ -1238,7 +1239,7 @@ Interfaces are denoted by their own keyword:
::
pragma solidity ^0.4.11;
pragma solidity >=0.4.11 <0.6.0;
interface Token {
enum TokenType { Fungible, NonFungible }
@@ -1300,7 +1301,7 @@ more advanced example to implement a set).
::
pragma solidity ^0.4.22;
pragma solidity >=0.4.22 <0.6.0;
library Set {
// We define a new struct datatype that will be used to
@@ -1374,7 +1375,7 @@ custom types without the overhead of external function calls:
::
pragma solidity ^0.4.16;
pragma solidity >=0.4.16 <0.6.0;
library BigInt {
struct bigint {
@@ -1515,7 +1516,7 @@ available without having to add further code.
Let us rewrite the set example from the
:ref:`libraries` in this way::
pragma solidity ^0.4.16;
pragma solidity >=0.4.16 <0.6.0;
// This is the same code as before, just without comments
library Set {
@@ -1565,7 +1566,7 @@ Let us rewrite the set example from the
It is also possible to extend elementary types in that way::
pragma solidity ^0.4.16;
pragma solidity >=0.4.16 <0.6.0;
library Search {
function indexOf(uint[] storage self, uint value)