Closed
Description
I think the following makes more sense compared to what we have now.
Now:
constantfunction should not modify the state (not fully enforced yet)constantstate variable (ie. the one in the class and not in a method) is evaluated every time it is called
After the change:
-
- the keyword
viewis introduced for functions (it replacesconstant). Calling aviewcannot alter the behaviour of future interactions with any contract. This means such functions cannot useSSTORE, cannot send or receive ether and can only call othervieworpurefunctions.
- the keyword
-
- the keyword
pureis introduced for functions, they areviewfunctions with the additional restriction that their value only depends on the function arguments. This means they cannot useSSTORE,SLOAD, cannot send or receive ether, cannot usemsgorblockand can only call otherpurefunctions.
- the keyword
-
- the keyword
constantis invalid on functions
- the keyword
-
- the keyword
constanton any variable means it cannot be modified (and could be placed into memory or bytecode by the optimiser)
- the keyword
5) the keyword[agreed to remove this functionality]volatileis introduced for variables, which read their referenced value every time (this is whatconstantdoes today to variables)
Any example of the volatile keyword:
contract A {
uint volatile number = block.number;
function a() returns (uint) {
return number; // this returns the *current* block.number every time it is called
}
}
I'm not sure the volatile option is useful and thus we might decide to remove it.
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
[-]Rename the current constant keyword (and reserve it for the future)[/-][+]Introduce a real constant keyword and rename the current behaviour[/+]Arachnid commentedon Sep 1, 2016
This seems like the wrong word;
constantfunctions are definitely not stateless; they often depend on state. If a new name must be used, perhaps something likeimmutableorpure(in the sense that a pure function is side-effect-free, which is what we're really describing)?axic commentedon Sep 1, 2016
I'm trying to find the word and stateless ia far from perfect. It should describe that the state is not modified.
Also additionally we could introduce real constant functions, which are indeed stateless and dont depend on the state. I.e. calculating something based on the inputs.
Arachnid commentedon Sep 1, 2016
Well, from a CS-theoretic POV, 'pure' is definitely the term you want. More informally, 'side effect free', but that's harder to condense into a keyword.
redsquirrel commentedon Sep 1, 2016
I think 'immutable' will be the least ambiguous to most developers.
axic commentedon Sep 1, 2016
I like pure, but are we likely to find another use for it? Does view as keyword make sense?
axic commentedon Sep 1, 2016
@redsquirrel immutable wouldmean to me that child classes cannot ovveride it.
redsquirrel commentedon Sep 1, 2016
@axic I suggest following Java and using 'final' for functions that cannot be overridden.
Arachnid commentedon Sep 1, 2016
I don't think so; certainly this is the only usage for the term I'm aware of.
I don't think that was under discussion here?
VoR0220 commentedon Sep 1, 2016
I agree that we should use pure...perhaps
strict? But I really like the idea ofpureas a side effect free input. Rather thanvolatilewhich conjures up bad imagery, why notstatic?chriseth commentedon Sep 1, 2016
nonmutating?VoR0220 commentedon Sep 1, 2016
too long...overly blunt descriptive. Less is more imo.
ethernomad commentedon Sep 1, 2016
readonly?63 remaining items