Standard library
- Dominant language
- C++
- Stars
- 25.7k
- Forks
- 6.2k
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 21
Description
This was recently mentioned in the EthOnline [Future of Solidity](https://axic.github.io/notes/summit/future_of_solidity/#/31) talk, but we have been discussing this here and there for the past months, and goes back as early as #228.
The goal is to move functionality out of the compiler into code written in Solidity and slowly build out a standard library -- lets call it `stdlib`. Files/contracts/functions from the `stdlib` would need to be explicitly imported, and would not be exposed implicitly. Initially this file would still be part of the compiler source code and included as a literal in the binary, but potentially in the future it could live outside should importing from content addressible locations turn more naturally supported by tools.
Functionality we want to move out / include:
1. Function available in the global namespace
2. Functions attached to certain types (such as those on `address`)
3. Potentially things like `block`, `tx`, and `msg`
4. Helpers to be used within assembly
There is some initial work available in https://github.com/ethereum/solidity/tree/stdlib
Contributor guide
Research direction
Review the existing work on the stdlib branch and the issue's earlier discussion, starting with how compiler-provided global functions, type functions, block/tx/msg values, and assembly helpers are currently represented. Done would require a defined, implemented Solidity standard library whose components are explicitly imported rather than implicitly exposed, initially embedded in the compiler.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- solidity
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100