From Classic to Core Solidity
summary
Core Solidity aims to replace Classic Solidity while avoiding a decade‑long Python 3 style split by using four concrete mechanisms: syntactic sugar to make Core look like Classic, deliberate omissions (no inheritance, try/catch, libraries) to remove legacy pain, automatic translation tools (a previous upgrade tool handles surface edits but fails on semantic changes like exponentiation associativity), and deep interoperability so projects can compile both languages in one project and call across compilers while handling memory layout and optimizer metadata.
AI-written summary · about
chapters (10)
- 0:00Classic to Core Solidity transition
- 1:04Core Solidity goals and roadmap
- 2:32Syntactic sugar for transition
- 4:39Syntax convergence
- 6:28Postfix types and parsing
- 8:15Automatic translation tools
- 9:17Classic and Core interoperability
- 10:39Function interoperability challenges
- 11:23Transition mechanisms and future plans
- 12:05Q&A
related talks
37mExperimental Solidity
01h 28mInto the Core Squeezing Haskell into nine Constructors
37mSolidity in 2022: Recent and Planned Features
15mWhat would Solidity look like if it was built today?
41mBattle of the Languages
12mPlank: The New Best Way to Develop Smart Contracts
01h 38mGHC Core Optimisations
01h 23mCarbon Language: An experimental successor to C++