# A1 - Notes on View and Pure modifiers in Solidity Why are there so many different modifiers for functions in the Ethereum EVM's programming language Solidity? To answer this question, you must first understand what the Ethereum blockchain is. The Ethereum blockchain can be accurately described as a 'decentralized immutable distributed ledger'. This may seem a little overwhelming, so let's break it down. * **Decentralized** - There is no single centralized entity responsible for the ledger, but rather an entire network / community. * **Immutable -** It cannot be altered. * **A distributed ledger** - A shared accounting of the information and transactions. So blockchains are just accounting systems that are openly shared by a wide number of people, where the information cannot be changed. We see words like `view` , `pure` or payable appear after the function name. These are called modifiers, but what do they mean?

From the Solidity docs cheetsheet - https://docs.soliditylang.org/en/v0.8.23/cheatsheet.html#modifiers

There are many modifiers to choose from. For example: * `payable` allows for ETH to be received by a smart contract address. * `immutable` is used for state variables to be written and stored at construction time of the contract and stored on the blockchain forever. The two that we are talking about today are the `pure` and `view` modifiers. ### View Modifier The `view` modifier declares that the function in question can only view and return blockchain data. It can’t write to or alter the state of the blockchain. One very common use of view functions is a `get` or a `getter` function. ```solidity function getUserBalance() public view returns (uint) { return users[msg.sender].userBalance; } ``` For example, if you have a state variable that can change, using the contract, you may need access to the information. These are created automatically, with the public modifier on the variable itself. Or if the variable is private, you will have to write your own. Furthermore, if you declare a function as a view function, there is absolutely no way of spending gas when calling that function. ### Pure Modifier The `pure` function declares that you can’t write, alter, or even read the state of the blockchain. These functions are used for calculations carried out, that are not part of transactions that will be recorded on the blockchain. 
function addition(uint a, uint b) public pure returns (uint) { 
    return a + b; 
}
One thing that they both have in common is that they are free to use, meaning they do not cost any gas. This is because they do not write any data to the blockchain. Of course, you could add some sort of calculation of math to a variable before it is returned, in a view function, if that is appropriate to your smart contract. In conclusion, the view and pure modifiers are essential building blocks of the solidity (and indeed any blockchain) programming language. Due to the economic incentives of the gas feature, a smart contract wants to try to use as little gas as possible. Smart contract developers can utilize the view modifier to access public blockchain information, without having to write a transaction to do so. In addition, they can use the `pure` modifier to carry out any mathematics off chain at no cost, before only using the return values in write functions, where necessary. The immutable nature of blockchains is certainly an excellent feature, which gives their trustless nature. The gas cost, however, is necessary, as it incentivizes people to write worthy information to the blockchains. `pure` and `view` functions give the programmer freedom over when and where to write to the blockchain. This allows for the most efficient smart contracts, whilst allowing blockchains to maintain their trustlessness. ### Feedback Again I prompt chatGpt for feedback using the following prompt: "please mark my assignment 1, provide me with constructive feedback: {paste the full report here}" **Content and Understanding:** Your essay effectively explains the purpose and functionality of the `view` and `pure` modifiers in Solidity. The introduction provides a good context about the nature of Ethereum blockchain, setting the stage for discussing the modifiers. Your explanations of the `view` and `pure` modifiers are accurate and clearly articulate their roles in Solidity smart contracts. **Strengths:** 1. **Contextual Introduction**: The initial discussion about Ethereum's decentralized nature provides a relevant backdrop for the topic. 2. **Clear Explanation of Modifiers**: You've accurately described the use cases for both `view` and `pure` functions and their impact on gas costs. 3. **Real-World Relevance**: Relating the modifiers to gas optimization and efficient smart contract development adds practical value to the explanation. **Areas for Improvement:** 1. **Structural Clarity**: The essay could benefit from more distinct paragraphing to separate the introduction, main discussion, and conclusion. This would enhance readability. 2. **Technical Detail**: While the descriptions are accurate, including a few code examples or scenarios where `view` and `pure` functions are used could deepen the understanding. 3. **Proofreading**: There are minor grammatical errors and some informal phrasing ("I know, 'decentralized immutable distributed ledgers' is a bit of a mouthful"). A more formal tone and careful proofreading would make the essay more polished. **Overall Impression:** The essay does a commendable job of explaining `view` and `pure` functions in Solidity. It demonstrates a good understanding of these concepts and their importance in smart contract development. With some structural refinement and the inclusion of specific examples or code snippets, your analysis could become more compelling and informative. Overall, you've shown a clear grasp of key Solidity concepts, which is crucial for developing efficient and optimized smart contracts. Keep exploring these essential aspects as they form the foundation of effective smart contract programming. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://simsimbutdifferent.gitbook.io/prompt_web3/lesson-3/lesson-3-assignments-and-excercises/a1-notes-on-view-and-pure-modifiers-in-solidity.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.