status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Use strong SHALL NOT language, thank you @carloschida

This commit is contained in:
William Entriken 2018-02-23 01:21:39 -05:00 committed by GitHub
parent 1a1295c903
commit e694c6d862
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
EIPS/eip-721.md
View File

@ -213,7 +213,7 @@ interface ERC721Enumerable /* is ERC721 */ {
The 0.4.20 Solidity interface grammar is not expressive enough to document the ERC-721 specification. A contract which complies with ERC-721 MUST also abide by the following: The 0.4.20 Solidity interface grammar is not expressive enough to document the ERC-721 specification. A contract which complies with ERC-721 MUST also abide by the following:
- [Solidity issue #3412](https://github.com/ethereum/solidity/issues/3412): The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: `payable`, implicit nonpayable, `view`, and `pure`. Your implementation must meet the mutability guarantee in this interface or you may meet a stronger guarantee. For example, a `payable` function in this interface may be implemented as nonpayble (no state mutability specified) in your contract. We expect a later Solidity release will allow your stricter contract to inherit from this interface, but a workaround for version 0.4.20 is that you can edit this interface to add stricter mutability before inheriting from your contract. - [Solidity issue #3412](https://github.com/ethereum/solidity/issues/3412): The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: `payable`, implicit nonpayable, `view`, and `pure`. Your implementation must meet the mutability guarantee in this interface or you may meet a stronger guarantee. For example, a `payable` function in this interface may be implemented as nonpayble (no state mutability specified) in your contract. We expect a later Solidity release will allow your stricter contract to inherit from this interface, but a workaround for version 0.4.20 is that you can edit this interface to add stricter mutability before inheriting from your contract.
- [Solidity issue #3419](https://github.com/ethereum/solidity/issues/3419): If a contract is not compliant with `ERC721` then it is not compliant with `ERC721Metadata` or `ERC721Enumerable`. ERC-721 implements the requirements of interface [ERC-165](https://github.com/ethereum/EIPs/pull/881). - [Solidity issue #3419](https://github.com/ethereum/solidity/issues/3419): A contract that implements `ERC721Metadata` or `ERC721Enumerable` SHALL also implement `ERC721`. sERC-721 implements the requirements of interface [ERC-165](https://github.com/ethereum/EIPs/pull/881).
- [Solidity issue #2330](https://github.com/ethereum/solidity/issues/2330): If a function is shown in this specification as `external` then a contract will be compliant if it uses `public` visibility. - [Solidity issue #2330](https://github.com/ethereum/solidity/issues/2330): If a function is shown in this specification as `external` then a contract will be compliant if it uses `public` visibility.
- Solidity issues [#3494](https://github.com/ethereum/solidity/issues/3494), [#3544](https://github.com/ethereum/solidity/issues/3544): Use of `this.*.selector` is marked as a warning by Solidity, a future version of Solidity will not mark this as an error. - Solidity issues [#3494](https://github.com/ethereum/solidity/issues/3494), [#3544](https://github.com/ethereum/solidity/issues/3544): Use of `this.*.selector` is marked as a warning by Solidity, a future version of Solidity will not mark this as an error.
@ -237,7 +237,7 @@ We chose specifically to avoid the word "token" because it has a well known, and
**Deed identifiers** **Deed identifiers**
The basis of this standard is that every deed is identified by a unique 256-bit unsigned integer within its tracking contract. This ID number MUST NOT change for the life of the contract. The pair `(contract address, deed ID)` will then be a globally unique and fully-qualified identifier for a specific deed within the Ethereum ecosystem. While some contracts may find it convenient to start with ID 0 and simply increment by one for each new deed, callers MUST NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a "black box". Also note that a deeds MAY become invalid (be destroyed). Please see the enumerations functions for a supported enumeration interface. The basis of this standard is that every deed is identified by a unique 256-bit unsigned integer within its tracking contract. This ID number SHALL NOT change for the life of the contract. The pair `(contract address, deed ID)` will then be a globally unique and fully-qualified identifier for a specific deed within the Ethereum ecosystem. While some contracts may find it convenient to start with ID 0 and simply increment by one for each new deed, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a "black box". Also note that a deeds MAY become invalid (be destroyed). Please see the enumerations functions for a supported enumeration interface.
The choice of uint256 allows a wide variety of applications because UUIDs and sha3 hashes are directly convertible to uint256. The choice of uint256 allows a wide variety of applications because UUIDs and sha3 hashes are directly convertible to uint256.