{"action":"opened","issue":{"url":"https://api.github.com/repos/ethereum/solidity/issues/4369","repository_url":"https://api.github.com/repos/ethereum/solidity","labels_url":"https://api.github.com/repos/ethereum/solidity/issues/4369/labels{/name}","comments_url":"https://api.github.com/repos/ethereum/solidity/issues/4369/comments","events_url":"https://api.github.com/repos/ethereum/solidity/issues/4369/events","html_url":"https://github.com/ethereum/solidity/issues/4369","id":336435576,"node_id":"MDU6SXNzdWUzMzY0MzU1NzY=","number":4369,"title":"Misuse of `view` modifier leads to weird side-effects","user":{"login":"NavyaZaveri","id":23720432,"node_id":"MDQ6VXNlcjIzNzIwNDMy","avatar_url":"https://avatars0.githubusercontent.com/u/23720432?v=4","gravatar_id":"","url":"https://api.github.com/users/NavyaZaveri","html_url":"https://github.com/NavyaZaveri","followers_url":"https://api.github.com/users/NavyaZaveri/followers","following_url":"https://api.github.com/users/NavyaZaveri/following{/other_user}","gists_url":"https://api.github.com/users/NavyaZaveri/gists{/gist_id}","starred_url":"https://api.github.com/users/NavyaZaveri/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/NavyaZaveri/subscriptions","organizations_url":"https://api.github.com/users/NavyaZaveri/orgs","repos_url":"https://api.github.com/users/NavyaZaveri/repos","events_url":"https://api.github.com/users/NavyaZaveri/events{/privacy}","received_events_url":"https://api.github.com/users/NavyaZaveri/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-06-28T00:47:56Z","updated_at":"2018-06-28T00:47:56Z","closed_at":null,"author_association":"NONE","body":"Here's a simple dummy contract to illustrate the problem: \r\n ```\r\n\r\npragma solidity ^0.4.24;\r\n\r\ncontract Contract{\r\n    uint public value = 0;\r\n \r\n    \r\n    //view modifier used inccorectly \r\n    function set_value(uint num) public view {\r\n        value = num; \r\n    \r\n    }\r\n    \r\n    function get_value() public view returns(uint){\r\n        return value;\r\n    }\r\n\r\n}\r\n```\r\nSay you call the follwing functions (in the same order):\r\n1) `set_value(100);`\r\n2) `get_value();`\r\n\r\nThe value returned turns out to be 0, not 100. The` view `modifier chunked beside` set_value(uint num) `isn't allowing for the state variable to be updated. \r\nThe problem is, a slip-up like this could be dangerous. While the compiler does throw a warning, when working on a large codebase this specifc warning could easily be lost in a mix of other harmless warnings, and could lead to unusual side-effects. It'd be really nice if it's possible to throw a compile-time error instead. "}}
{"actor":{"display_login":"NavyaZaveri"}}