Solidity: What is the difference between `view` and `constant`?

Question

Solidity 0.4.16 introduced the view and constant function modifiers. The documentation says:

constant for functions: Same as view.

Does this mean view is just an alias for constant? If so, why do we need it?

Answer 1

This is discussed here: https://github.com/ethereum/solidity/issues/992 and has been partially implemented in the change you noted.

As I understand it, the point is that constant is misleading (constant functions don't necessarily return constant results), and not particularly nuanced. The changes when complete will introduce two replacement keywords: view and pure which are intended to be more meaningful and useful.

From the GitHub issue,

Now:

• constant function should not modify the state (not fully enforced yet)
• constant state variable (ie. the one in the class and not in a method) is evaluated every time it is called

After the change:

1. the keyword view is introduced for functions (it replaces constant). Calling a view cannot alter the behaviour of future interactions with any contract. This means such functions cannot use SSTORE, cannot send or receive ether and can only call other view or pure functions.
2. the keyword pure is introduced for functions, they are view functions with the additional restriction that their value only depends on the function arguments. This means they cannot use SSTORE, SLOAD, cannot send or receive ether, cannot use msg or block and can only call other pure functions.
3. the keyword constant is invalid on functions
4. the keyword constant on any variable means it cannot be modified (and could be placed into memory or bytecode by the optimiser)

Answer 2

As described here,

Functions are declarable as view, making them promise not to modify the state, thus only being used for viewing the state.

Here’s a list of conditions for a statement to be considered as “modifying the state”:

1. State variables being written to.
2. Events being emitted.
3. Other contracts being created.
4. selfdestruct being used.
5. Ether being sent via calls.
6. Calling functions that are not marked view or pure.
7. Low-level calls being used.
8. Inline assembly containing certain opcodes being used