Change name and symbol functions to view for Metadata extension

[AnAllergyToAnalogy]

The mutability of the name() and symbol() functions in the metadata extension should be view not pure. Having it set to pure assumes that the token name and symbol will be hard-coded into the contract functions, rather than set (for example, in the constructor).

The mutability guarantee rules allow you to go stricter, (ie move from view to pure), but not the other way, so dropping it down to view wouldn't take anything away but would allow for these variables to be set and stored elsewhere in the contract.

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-X.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your Github username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

[eip-automerger]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

• EIP 721 requires approval from one of (nastassia.sachs@protonmail.com, @fulldecent, @dete, @dekz)

[fulldecent]

Dropping to view DOES take something away. It removes the interface consumers' confidence that the name and symbol will not change in the future. Presently it is possible to cache this value. With the proposed change it would not be possible to cache.

From the hip I am favorable to this change because most implementations I have seen are ignoring the standard and are implementing the way you describe above.

To fully supporting this change, I'd like to see facts:

• Which contracts are currently deployed to mainnet and are they using pure or view?
• From the perspective of the identified use cases in the standard is there a conceivable scenario where the reduced guarantee would hurt them, and is it likely?

[fulldecent]

Also conceding that in EVM, purecall is not actually enforced. Discussion at #195

[fulldecent]

I have advertised this PR at:

• The Gitter https://gitter.im/ETH-NFT/Lobby
• My Twitter https://twitter.com/fulldecent/status/994411872404279297
• My LinkedIn https://www.linkedin.com/feed/update/urn:li:activity:6400180337472786432

[xpepermint]

Contract deployment would be much easier and more flexible with view.

[fulldecent]

I have reviewed existing mainnet implementations that I could find. Several have violated the pure rule. I am not yet sure how to interpret this data to decide if we should accept this PR.

But I know we must make a decision before Thursday May 17, 2018.

Project	Mainnet	Metadata visibility
CryptovoxelsProperty	0x3a81d175f3dfd76e5013a57772929ed85f7d6380	view
KnownOriginDigitalAsset	0xdde2d979e8d39bb8416eafcfc1758f3cab2c9c72	view
CryptoCrystal	0xcfbc9103362aec4ce3089f155c2da2eea1cb7602	view (Contract is not ERC-721 compliant in other ways as well)
EthergotchiOwnershipV2	0x449f5c827cf7726cc5f181090aa147ca5fb88a40	pure
SuSquares	0x6731560e455537c9f088ea02a47a0ecfa28a9231	pure
Dark	0x1f28211cd78363c7e0d44a90157017422599526c	pure
BlockchainCutiesCore	0xd73be539d6b2076bab83ca6ba62dfe189abc6bbe	pure
ChibiFighters	0x71C118B00759B0851785642541Ceb0F4CEea0BD5	pure
Etherbots	0xd2f81cd7a20d60c0d558496c7169a20968389b40	pure
CryptoKitties	0x06012c8cf97bead5deae237070f9587f8e7a266d	pure (but advertises as view)
Decentraland	0x62a4489da2a0dd1aaab13546529fef6f365aee6e	view (but this is upgradable)

[AnAllergyToAnalogy]

An argument against changing from pure to view would be that since ERC721 is for non-fungibles, which presumably have some purpose or meaning beyond just adhering to the standard, it's unlikely that the exact same implementation will need to be deployed multiple times with just changes to the metadata (as opposed to something like ERC20, where just deploying a compliant token contract can serve its full purpose).

With this in mind, the need to specify name and symbol at the time of deployment may not outweigh the benefits of keeping the functions as pure.

[fulldecent]

Further I have reviewed all the prior art tokens standards which are cited from the ERC-721 paper: ERC-223, ERC-677, ERC-827. None of these use pure. They all use constant, which is outdated on its own.

[fulldecent]

DECISION: I approve this change.

RATIONALE: Perhaps the ideal solution is to wait for Solidity to support Swift-style immutable declarations like:

pragma solidity ^0.4.22;

contract BagOfCoins {
    int constant public a;
    constructor() {
        a = 6; // If this line is missing then ERROR: constant a is not initialized
    }
}

However, idealism is not in scope for this standards specification, and no such change is being considered in Solidity.

Practically, the benefits for contract authors to use storage for implementing the contract name and symbol has many benefits. And practically, the EVM does not yet support PURECALL, so the meaning of pure is suggestive at best.

I have reviewed the entire standard text to ensure the rationale is consistent after the change. And also I have reviewed all other cited token standards and every deployed 721 contract on mainnet to support this decision, as referenced above. This change is entirely additive for contractor authors and does not break any known implementation on the blockchain.

[fulldecent]

@AnAllergyToAnalogy Please click the repull button above. So we can merge this. Thank you for your review and your help!

[AnAllergyToAnalogy]

@fulldecent No worries, glad to be able to contribute to ERC721, I think it's an important standard. Thanks for accepting my pull request.

[fulldecent]

@AnAllergyToAnalogy Your name is epically difficult to DDGTFW. What is your Twitter please?

[AnAllergyToAnalogy]

@cashtagyolo