###### tags: ``Team Admin``,``Ecosystem`` # Solidity Language Design Calls: Rolling Agenda :::success ## [Next design call](#Next-design-calls) 🗓️ When: Wednesdays, [3 PM CET/CEST](https://www.timeanddate.com/worldclock/converter.html?iso=20230215T140000&p1=tz_cet) 🖥️ Call location: https://meet.soliditylang.org/ ::: :::info **How to add a topic:** If you have a topic that want to discuss, simply add it bellow in our "[Backlog of topics to discuss](#Backlog-of-topics-to-discuss)" with: - a link to an issue - or forum post - and your initials in ``[ ]``. ::: :::warning ⚠️ Please **do not delete previous agendas**, instead **add new items to the Next Design call agenda**, or **copy an existing one** if you want to re-discuss it. ::: If you're interested, you can also read our last years agenda[^1]. [^1]: [2022 Design Calls Agenda](https://notes.ethereum.org/Il4T7XGtRNOTKGfS3aUeLA) ## Next design calls: ### Backlog of topics to discuss - [SOL] [ℹ️ ADD YOUR TOPICS HERE](https:/x/github.com/ethereum/solidity/issues)👇 - Possible improvements of Yul-EVM code transform. - Look at issues in the milestones and clean them up - SMTChecker: Interfacing with SMT/CHC solvers - Changing the Yul AST during optimization to use numeric names (a pair of name ID and a monotonic index for newly generated names) - potentially with (for now unused) support for phi-nodes as well. - Discussions around via-IR - Awareness of https://eips.ethereum.org/EIPS/eip-3074 going into Prague - Review [Sourcify's metadata improvement suggestions](https://github.com/ethereum/sourcify/issues/1523) - Fixed point stuff revisited - Verkle Trees ## Notes ## Agenda for 2024-10-30 - Devcon Talk State - Some initial task for Erik while we're in Phuket/Devcon? ## Agenda for 2024-10-23 - [Yul object names with dots are accepted but ambiguous #15540](https://github.com/ethereum/solidity/issues/15540) - decision: disallow dots, non-breaking - [Insufficient check for uninitialized storage pointer access #14021](https://github.com/ethereum/solidity/issues/14021) was at the core of one of the submissions in the underhanded contest, which means it should prioritized a bit more. - [Fix verbatim control flow size effects. #15542](https://github.com/ethereum/solidity/pull/15542) - We give `verbatim` worst `SideEffects`, but not `ControlFlowSideEffects`. - Does it actually result in optimizer doing something wrong or is it just a theoretical problem? - Probably yes: try a storage write that will be optimized out due to revert/termination. - Decision: not an important error, documentation actually says that verbatim block should not change control flow. - Add a warning about previous version in the docs. - Multi-level break in Yul ``` do { if (<someCond>) continue; } while(<cond>); ``` ``` let isFirstRun := 1 for myloop {} true {} { if iszero(isFirstRun) { if iszero(<cond>) { break } } .... isFirstRun := 0 } for mylabel {} true {} { for {} true {} { break<mylabel> break[mylabel] break(mylabel) break:mylabel break->mylabel } mylabel: { break } for mylabel {} true {} { break(2) break } } ...break 2 target... ``` ## Agenda for 2024-10-16 - Issue linked in Matterlabs doc: https://github.com/ethereum/solidity/issues/15142 - Quick follow-up on: `do ... while` loops are inherently less gas efficient in code compiled via IR due to lack of jumps or native `do ... while` in Yul. [Should we have them in Yul?](https://github.com/ethereum/solidity/issues/15442#issuecomment-2378257690) - education session about ABI encoding? ## Agenda for 2024-10-09 - education session about ABI encoding - `do ... while` loops are inherently less gas efficient in code compiled via IR due to lack of jumps or native `do ... while` in Yul. [Should we have them in Yul?](https://github.com/ethereum/solidity/issues/15442#issuecomment-2378257690) ## Agenda for 2024-10-02 - Look again at Prague https://eips.ethereum.org/EIPS/eip-7600 - Check other hardhat workarounds: https://github.com/ethereum/solidity/pull/15461 (@matheus) - https://github.com/ethereum/solidity/pull/15252 ## Agenda for 2024-09-25 ## Agenda for 2024-09-18 - Storing nightlies in solc-bin on GitHub is becoming more and more of a nuisance - workarounds are needed to even clone the repo, `bin/` file listing is so long it errors out on GitHub. - Is preserving historical nightly builds even useful to anyone? I think they're relevant only for a very short time. And more often than not we're interested in sharing a binary from an unmerged PR rather than `develop`. - Would deleting them all and only having nightlies from the last 30 days on CircleCI be good enough instead? - Could we get rid of them more permanently, e.g. by archiving the current solc-bin and starting over with a new directory structure and without nightlies? - If we do want to preserve them, could we move them to something less permanent, e.g. make them pre-releases in solc-bin? - Conclusion: - Short term: do nothing - Long term: nice IPFS setup; split between releases and nightlies (different subdomains, different easier upload mechanism for nightlies and feature branch releases, etc.) - State of Transient Storage - State of EOF - State of Storage Layout Specification https://github.com/ethereum/solidity/issues/597 - Next steps: - Prepare final spec showing what we'll implement and post in the issue. - Announce it. ## Agenda for 2024-09-11 - The external "contant evaluator" PR does not seem to provide any gas savings, even when moved after FunctionSpecializer. Ask the contributor to investigate. - It also does not make any visible difference in compilation time benchmarks. But this does not prove much - it might just not have enough input to work on. - Broken `bin/soljson-latest.js` symlink during last release. We should finally fix [#13508](https://github.com/ethereum/solidity/issues/13508). ## Agenda for 2024-09-04 - Nick's fixed point udvt assembly idea ``` fixed8x80 <=> uintABC function f(fixed8x80 x) external { fixed8x80 y = x; assembly { y := x } } "f(fixed8x80)" ``` - abi encoded errors request by Hadrian https://github.com/ethereum/solidity/pull/14974#issuecomment-2324307483 - https://github.com/ethereum/solidity/issues/15388 - SMTChecker going into maintenance mode; Paweł Gębal to potentially move to other Solidity work - are we interested in that? Notes: ``` type error is bytes memory; function CustomError(uint x) returns (error) { return error.wrap(abi.encodeWithSignature("CustomError(uint256)", x)); } error someError = CustomError(42); /// <- this is the costly part return bytes(someError); ``` ## Agenda for 2024-08-.. - Review [Sourcify's metadata improvement suggestions](https://github.com/ethereum/sourcify/issues/1523) ### Agenda for 2024-08-28 ### Agenda for 2024-08-21 - Quick Chat about Erik - Is the ossfuzz stuff settled? - Need dedicated EOF review sessions. ## Agenda for 2024-08-14 - SMTChecker SMTlib-switch progress - Review/progress strategy for [EOF PR](https://github.com/ethereum/solidity/pull/15294) - (Hopefully) final review pass on [Legacy Value-Type Transient Storage Codegen](https://github.com/ethereum/solidity/pull/15257) - "lower review intensity required"/"low hazard risk" label for PRs? maybe "moderate risk" something hidden ### Agenda for 2024-08-07 - Some discussion around removing typed yul and simplifying Yul ASTs, etc. - Some coordination about the Madrid SSA CFG work. - Some reviewing. ### Agenda for 2024-07-24 - [EOF Presentation](https://drive.google.com/file/d/1LE2YSMh7_8XvGZruSd3wLEdOBXKtz6jy/view?usp=drive_link) - EOF PR Review and Merge Planning - Post EOF PR Planning - Assembly JSON import/export for EOF functions (Madrid collaboration) - Source mappings and various other compiler artifacts. - Remove stack-to-memory; adjust code transform to exploit EIP-663 - High-level Language Changes? => At least: salted create address calculation ### Agenda for 2024-07-17 - Opinions on https://github.com/ipsilon/eof/pull/144 - we should at least comment. - Should we expose whether the target is EOF as language construct? Builtin address calculation primitive? - How to proceed with https://github.com/ethereum/solidity/issues/597 - Collision-detecting: that's bit weird - collision detection is basically the entire point of all this in the first place :-D. Or is the point collision-freeness wrt mappings and not for base locations? That we cannot do anyways. - https://blog.ethereum.org/2024/07/08/attackathon - Readthedocs **deprecation of Sphinx context injection at build time** mail: check if and how that affects us. - https://notes.ethereum.org/BNATXOfARBCF09BcZmZ6yQ ### Agenda for 2024-07-10 - How to proceed with https://github.com/ethereum/solidity/issues/597 - Check-in on Yul object hashing for optimization deduplication (are we fine with that approach for now?) - How to proceed with https://github.com/ethereum/solidity/pull/15238 ### Agenda for 2024-06-24 - Another session about [Allow specifying storage locations #597](https://github.com/ethereum/solidity/issues/597) ### Agenda for 2024-06-12 - Another session about [Allow specifying storage locations #597](https://github.com/ethereum/solidity/issues/597) - Check what's holding up transient storage PR. - Anything needed for next week? (@ekpyron on vacation) ### Agenda for 2024-06-05 - [Allow specifying storage locations #597](https://github.com/ethereum/solidity/issues/597) in the context of EIP-7702 - Disadvantage of specifier in contract body: breaking (arbitrary type names); order of contract body elements; multiple mentions, etc. - Kamil dislikes prefix specifiers - Postfix - it should probably be after the inheritance specifiers, since otherwise scoping is weird. #### Syntax brainstorming ```solidity abstract contract Example { /// @custom:storage-location erc7201:example.main struct MainStorage { uint256 x; uint256 y; } //address owner; MainStorage virtual $; //address virtual owner; function _getXTimesY() internal view returns (uint256) { return $.x * $.y; } } contract ExampleWithConcreteStorage is Example { layout{slot: keccak("...ABC...")} MainStorage override mainStorage; storage for contract Example override; address override owner; } contract ExampleWithConcreteStorage is Example, Ownable { using storage{slot: keccak("...ABC...")} for Example; using storage{slot: keccak("...ABC...")} for owner; } ``` ```solidity abstract contract Example { /// @custom:storage-location erc7201:example.main struct MainStorage { uint256 x; uint256 y; } //address owner; MainStorage $; //address virtual owner; function _getXTimesY() internal view returns (uint256) { return $.x * $.y; } } contract ExampleWithConcreteStorage is Example storage of Example at <expr>; { } ``` ### Agenda for 2024-05-29 - [Allow specifying storage locations #597](https://github.com/ethereum/solidity/issues/597) in the context of EIP-7702 - Any cases in which location should be independent for base contracts from derived contracts? - Make it a contract definition property, which could also syntactially distinguish between inheritance behaviour - Decision: https://github.com/ethereum/solidity/issues/597#issuecomment-2137917945 ### Agenda for 2024-05-15 - Final pre-release checkin - Post-release planning - require with custom error in legacy (via call into the Yul function) - Progress on Transient Storage - Yul AST refactor with numeric IDs; refactor of data structures in DataFlowAnalyzer - Progress on SSA Transform and Forward Yul->EVM codegen - Evaluate Ipsilons upcoming EOF draft - Bugfixing - Merge strategy for EthDebug PRs - C++ Coding Style: auto: https://github.com/ethereum/solidity/pull/15077 - Somewhat related: https://github.com/ethereum/solidity/issues/14403 ### Agenda for 2024-05-08 - How to proceed with [Add abi.encodeError #14974](https://github.com/ethereum/solidity/pull/14974). - SMTChecker: Upgrading `CVC4` to `cvc5` using SMT-LIB2 interface - [https://github.com/ethereum/solidity/pull/15078](https://github.com/ethereum/solidity/pull/15078) - Should we go through intermediate step (`cvc4` using SMT-LIB2 interface)? - No tests using `cvc4`? - No `cvc4` in OSX job in CI? - If there is time: small summary of current projects for Moritz - Ping tooling to try a nightly with JSON-corner-cases if they have any ### Agenda for 2024-04-17 - General Focus Areas - Yul Optimizer Performance - Research worst cases: - how much is the code transform roundtrip (to be solved by code transform work) - how much is data flow analyis - in particular: what's special about worst cases - number of variables? Control flow? - Community-Collection of bad case - - Yul Code Transform (Rodrigo & Fe & Madrid) - EthDebug - One High-Level Language Feature ### Agenda for 2024-04-10 - [Code Deduplication Creates Wrong Source Mappings #14930](https://github.com/ethereum/solidity/issues/14930) - Marko says that arbitrarily choosing one of the locations creates problems more often than it helps. - In the long term ethdebug will solve this, but can we either allow disabling it or mark such locations as guesses in the short term? Marko would be willing to work on implementing that. - Is adding a new element to the source location tuple breaking? - Decision: we're still inclined to wait for a proper solution with ethdebug (more details will be posted in the issue) - [New macOS Universal Binaries are signed #14813](https://github.com/ethereum/solidity/issues/14813) - is there anything else we can do to get rid of the ad-hoc signature or do we just leave it at that? - Wait for complaints. - How to handle the contribution: [Add binary string/literal/number to solidity and yul #15003](https://github.com/ethereum/solidity/pull/15003) - Mention that it's uncommon to jump on closed issues, better to talk to us before picking one up. - Ask to join the Matrix channel or a design call to avoid spending effort on PRs we would not accept. - Mention that adding the `bin` keyword is breaking so we can't accept that as-is but we're open to accepting a PR that's just the part that adds support for `0b` prefix. - It would also be easier to us to review it in smaller steps. Especially a PR with just the Solidity support would be a better as the first step. Then Yul support could be added in a separate PR on top of it once the first one is merged. ### Agenda for 2024-03-27 - High-Level Support for Transient Storage - Value Type Only (as state variables only)? - Parser Hack - Layout? - Legacy vs via-IR? - Compiler Output Artifacts about Layout - Limited optimizer support - Assembly Access - Later: reference types: - First version: non-convertible to other locations. ### Agenda for 2024-03-06 - Talk about the upcoming release ### Agenda for 2024-02-28 - require with custom errors (https://notes.ethereum.org/g6f0Xi6JQySEFqLX7jyqnw) - results of optimizer research (sequence + libevmasm CSE) - Cancun release: - Schedule March 13th/14th (Cancun is scheduled for March 13th) - Make cancun default EVM version. - Dial down the transient storage warning to annoy people a bit less. - Ideally we also still manage to (optionally): - Have an initial tweak of the optimizer sequence (with a minimal impact, but some performance improvement) - A nice feature to also ship - like custom errors above. - handling of semver breaking changes (https://github.com/ethereum/solidity/pull/14886) ### Agenda for 2024-02-21 - JSON Schema Grant? (https://github.com/pboettch/json-schema-validator/issues/153#issuecomment-1076384370) - Initial quick report about Optimizer Sequence and libevmasm CSE. - Survey evaluation (continued) ### Agenda for 2024-02-07 - EthDebug implementation: - Current mechanisms for transporting debugging data. - Initial plan for extending to account for EthDebug. - Stack shuffling ### Agenda for 2024-01-10 - Style Guide (handing it over to the community) - Experimental Solidity Codegen next steps ### Agenda for 2023-12-20 - Cancun support ### Agenda for 2023-12-06 - ReadTheDocs WebHook Integration Secret Requirement: Hello, Previously, manually configured webhooks from integrations did not have a secret attached to them. In order to improve security, we have deployed an update so that all new integrations will be created with a secret, and we are deprecating old integrations without a secret. You must migrate your integration by **January 31, 2024**, when they will stop working without a secret. We are contacting you because you have at least one integration that does not have a secret set. These integrations are: If you aren't using an integration, you can delete it. Otherwise, we recommend clicking on "Resync webhook" to generate a new secret, and then update the secret in your provider's settings as well. You can check [our documentation](https://docs.readthedocs.io/en/stable/guides/setup/git-repo-manual.html) for more information on how to do this. You can read more information about this in our blog post: . Keep documenting, Read the Docs Note: already settled, just need to quickly confirm that it keeps working. ### Agenda for 2023-11-08 - Discuss bug blog post. - https://github.com/ethereum/solidity/pull/14673 - AST schemata open question (if applicable) ### Agenda for 2023-11-01 - Discuss optimizer options (current adjustment and long-term plan). - Settle on verbatim bug description and release date. ### Agenda for 2023-10-18 - Discuss 0.8.22 release comms: https://notes.ethereum.org/wwMq--okTneeu07vYAERxQ ### Agenda for 2023-10-04 - Future of `legacyAssembly` - is it going to be deprecated and removed? - Currently we have two assembly formats: 1. `assembly`/`--asm` (text) 1. `legacyAssembly`/`--asm-json`/`--combined-json asm` (JSON) - `legacyAssembly` was called that ever since Standard JSON was introduced. - @chriseth says that the legacy format was not machine-readable, and he wanted to remove it eventually. Though it's not certain if it was really the same as current legacy format (the non-machine-readable one was apparently text, not JSON). - [comments from @chriseth and @axic on a related bug](https://github.com/ethereum/solidity/issues/8171#issuecomment-588184845) - We're using the legacy JSON format for the assembly import feature that's being implemented. If we accept it as input, we should also be able to output it so that it can be modified and fed back. - The naming is confusing (I never remember which one is JSON) and also tells users to stay away from it (legacy features eventually go away). If it's going to stay, perhaps it should be renamed to `assemblyJSON`. ### Agenda for 2023-09-13 - Experimental type system: - Rough next steps. - Continue splitting/moving builtins. - Split into type variables and free types - Construct SCC forest from call graph. - Use SCC forest for ordering type inference. - After the above: Take care of current quirks (types for type-expressions; member access construction; type variables in signatures & syntax for type variables) - Independently: Extension of IR Generation with IRVariables. - Later: - algebraic data types (sounds worse than it is); generalized type classes (will take some doing); literals. Then basically done with first milestone in terms of expressivity; can refine syntax (note: reference types are next milestone) - Also need: testing-only option for using in-tree stdlib files (to avoid annoyance of having to recompile the compiler for development) - Split between fixed free type variables and schematic type variables. (Including: flukes in current inference in presence of explicit type variables that can still be unified) ### Agenda for 2023-09-06 - Yul Optimizer still depending on AST IDs: https://github.com/ethereum/solidity/issues/14494 https://github.com/ethereum/solidity/issues/14535 - Another quick look at the recent (likely false-positive) vulnerability report; potentially still fix the alignment in question. ### Agenda for 2023-08-23 - Experimental type system: - AST Translations (postpone!) - Polymorphic recursion as complication (reject!) - Challenges and advantages of deferred unification - Advantages of further generalization by unification via solver - Compile-time constant evaluation (stack size as type class!) - "Early" monomorphization? ### Agenda for 2023-08-16 - verbatim in inline assembly https://github.com/ethereum/solidity/issues/12067 - Inheritance improvments and external interfaces ### Agenda for 2023-08-09 - Native WebAssembly builds and implications for solc-js - Exception support in browsers may be sufficient for native WebAssembly builds today - Implications for solc-js and tooling and backwards-compatibility (maintain soljson.js and soljson.wasm? Is rebuilding old versions feasible here (compiler versions & exception support)?) - Overview of Dominators (out of time for: and brainstorm on possible improvements of Yul-EVM Code transform.) ### Agenda for 2023-08-02 - Initial Verkle-Tree discussion (long-term awareness) ### Agenda for 2023-06-21 - Separate namespaces for terms and types and name and type resolution. - Modernization of the scanner. ## Past design calls ### Old Backlog of topics - inference of data locations together with mixed locations and tying locations to types (https://github.com/ethereum/solidity/issues/13730) - We need to gather possible corner cases for discussion. - Codebase purge: - Drop support for old EVM versions - Drop snap config - Drop old EVM code transform - Drop cvc4? - Drop typed yul (breaking?) - Drop assorted scripts - Drop our custom Homebrew formula for older compiler versions - [breaking?]: - solc --link - --combined-json - abi.encodePacked - abi.encodeWithSignature/Selector - ABIEncoderV1 - outdated assembly options https://github.com/ethereum/solidity/issues/13714 - libraries - Schedule dedicated design calls for the upcoming larger tasks that are still under-defined: - Generics - owned by Daniel - Compile-time-constant expression evaluation - owned by Daniel - Better memory optimizations - owned by Chris, still in research phase, not yet in an explanatory stage, documented in hackMD here -> https://notes.ethereum.org/WnsIlf8RSASJFr8S7m5yvQ - Code data location / value type immutables - owned by Daniel - ...? - Decide whether it is worth adding type definitions to ABI and compiler I/O standard in solc-js (https://github.com/ethereum/solc-js/pull/630). And what would be the best way to maintain that (e.g., using a JSON schema). - Should we allow omitting location for function parameters in interfaces just like we decided to do for function pointers? - Do we want tangential features like [Yul formatter #13550](https://github.com/ethereum/solidity/issues/13550) or [Exposing evmasm::disassemble a "poor man's disassembler" #12753](https://github.com/ethereum/solidity/issues/12753) in the compiler? ### Agenda for 2023-06-14 - [x] Policy on awarding bounties for codegen errors that do not qualify as proper security vulnerability. - [x] Statements as expressions in experimental solidity; match, if - [x] Syntax brainstorming: type classes, instantiations, free type variables Notes: https://notes.ethereum.org/@solidity/ByhPnEwwh general preference towards angular brackets; keeping the issue open, though ### Agenda for 2023-05-17 - [x] Decision on [User-defined literal sufixes](https://github.com/ethereum/solidity/issues?q=literal+suffixes+is%3Aopen+) - Decision: Doing nothing about it and going for the experimental route. - Legacy code gen will be too expensive. - ~~Alternative: restricting it to via-ir (initial scope).~~ - It would mean refactoring the PR. - [ ] Decision: Restricting the experimental pragma to constantinople. - [[experimental] Postfix types. #14237](https://github.com/ethereum/solidity/issues/14237) - Split the work between Nikola and Matheus - [Generalizing Hindley-Milner Type Inference Algorithms](https://www.researchgate.net/publication/2528716_Generalizing_Hindley-Milner_Type_Inference_Algorithms) - Experimental Solidity Type Checking - Immutables ### Agenda for 2023-05-10 - Weekly long-term light syntax brainstorming: lambda functions & higher-order functions as replacement for modifiers - Notes: https://notes.ethereum.org/6-h78QXOTbKkufpQj5ZpFg ### Agenda for 2023-05-03 - [Support EIP-712 typehash in type #14157](https://github.com/ethereum/solidity/issues/14157) - Next steps for [Markella](https://github.com/GiokaMarkella) on [Add support for Yul ASTs output](https://github.com/ethereum/solidity/pull/14177) - [Introduce solidity-next pragma](https://github.com/ethereum/solidity/pull/14168) - Naming it `pragma experimental solidity` for now. - We still have some (irrelevant) experimental functions. - Adjust the Solidity Roadmap to reflect the new changes. - [EIP-1153: Transient storage opcodes](https://eips.ethereum.org/EIPS/eip-1153) in Cancun - `TLOAD` and `TSTORE` are transaction local. - Expose the opcodes (people won't like it) **with limited highlevel support**. - Cancun should be out in Q4. - [Add support to import evm assembly json (updated). #13673](https://github.com/ethereum/solidity/pull/13673) - [Add support to import AST via Standard JSON. #14171](https://github.com/ethereum/solidity/pull/14171) - [Add support for Yul ASTs output #14177 ](https://github.com/ethereum/solidity/pull/14177) ### Agenda for 2023-04-26 - We postpone merging the literal PR and discussing it until after the next release. - We may decide to limit it only to the IR codegen or maybe even completely drop it. - JSON schemata - weighing effort against benefits (long- and short-term) - considering in combination - Two options: use a standalone schema validation library or use `nlohmann/json`, which has it built-in, but requires us to migrate to that library at the same time. - Decision: we won't do that yet, but we'll consider it after all the JSON import work is finished. ### Agenda for 2023-04-19 - Implementing the new pragma for upcoming experimental features. ```solidity pragma experimental solidity-next; ``` - Stdlib import syntax. ### Agenda for 2023-04-12 - More discussion about postfix typing. ```solidity= let x:uint256 = 42; uint256 x = 42; uint256[3][4]; uint256[3][4] x; x[3][4]; struct S { uint256 x; } S[3][4]; let x:(uint256,uint256) = ...; function f(a, b) -> c:uint256 { (a:uint256) + complexFunction(b,1:uint256) } cond ? 1 : 2 cond ? 1:uint256 : 2:uint256 cond ? (1:uint256) : (2:uint256) let // Not a severe change // "More than half of the community is in favour of adding it" // "The var keyword is now disallowed to favor explicitness." In solidity 0.5 // https://docs.soliditylang.org/en/v0.8.19/050-breaking-changes.html ``` - The type system we're aming for: Hindley Milner Type Inference with Type Classes restricted by Functional Dependencies - [Further concerns about making `shanghai` the default EVM version](https://github.com/ethereum/solidity/pull/14107#issuecomment-1503663287) and the effect of that change on tools and non-mainnet EVM implementations. ### Agenda for 2023-04-05 - [Shanghai Support #14073](https://github.com/ethereum/solidity/issues/14073) - Shanghai introduces a new opcode (`PUSH0`) that is not available in L2 EVM implementations yet (e.g. Optimism). Making it the default EVM version will result in the default compiler output not being deployable there. - We have always been considering Ethereum mainnet as the primary target so that's the main consideration when choosing the default. - This should be just a short-term problem. If it persists in the longer term, it's the frameworks (which know the target deployment network) that should prevent the user from choosing an unsupported EVM version. - On our side should make sure that the potential issue is pointed out in the release notes. ### Agenda for 2023-03-22 - Proper tuple types. - Sum and product types in the language and parsing issues that come with it. - Random notes: https://notes.ethereum.org/8TiA-epPQ82t4cgWm5UlKw - From discussion after the call: we'll likely go with introducing postfix types. ### Agenda for 2023-02-15 - Quick decision about what to do about [The old optimizer breaks public function equality #13969](https://github.com/ethereum/solidity/issues/13969). - Decision: disallow. Warning now, error in a breaking release. - Syntax proposals for extending `try`/`catch` to handle local reverts, [from @chriseth](https://github.com/ethereum/solidity/issues/13869#issuecomment-1422879881) and [from @cameel](https://github.com/ethereum/solidity/issues/13869#issuecomment-1423021751). - Another idea: replacing `try`/`catch` with `tryCall()` and match expressions. - Hari: We could ignore `try`/`catch` for now, give people `abi.tryDecode()` and see if it's enough for them. - [`try`/`catch` for `abi.decode()` or `abi.tryDecode()`](https://github.com/ethereum/solidity/issues/10381) - Decision: - Try to get feedback from the community on the [`internal catch`/`external catch` proposal](https://github.com/ethereum/solidity/issues/13869#issuecomment-1423021751). This is something that we could potentially implement right away. - In the meantime we can see if we can do anything about `abi.tryDecode()` (but we don't really have everyting needed to implement it right now). ### Agenda for 2023-02-08 - which keyword to use for dynamic immutables; new developments potentially counterindicative for using ``code`` (EOF may transition ``codecopy`` -> ``datacopy``) ([Code data location (0.9 release)](https://github.com/ethereum/solidity/issues/13723), [Immutable dynamic arrays](https://github.com/ethereum/solidity/issues/12587) - internal/external/public library function inconsistencies: - [Calls to attached functions in a library do not always match equivalent direct calls in terms of being internal/external](https://github.com/ethereum/solidity/issues/13908) - Goal: deprecate, remove, replace; - Immediate step: gather data from various sources about external/public library functions in particular - Other possible sources of user information: Twitter Survey: If people complain, we can write a short blogpost explaining why we are deprecating it. - Example of project using it is [forge-std](https://github.com/foundry-rs/forge-std/blob/master/src/StdMath.sol#L4). - try...catch and decoding & extcodesize failures - [Unable to use try/catch to reliably catch errors](https://github.com/ethereum/solidity/issues/13869) - [try/catch doesn't catch some call errors.](https://github.com/ethereum/solidity/issues/12725) - and probably a few others [try/catch block does not catch the exception caused by EXTCODESIZE check on external calls](https://github.com/ethereum/solidity/issues/11373) - The problem is that changing the behavior of the `catch` clause would be breaking. - There were ides on how to change it in a non-breaking way from @chriseth and @cameel. They'll write them down in the issue and then we'll evaluate. - abi decoding *to* calldata types https://github.com/ethereum/solidity/issues/13518 - good change; technically breaking - question: do it anyways? - Decision: take being breaking seriously - Consider allowing data locations in type tuple on RHS! - Codebase purge: - Drop EWASM backend (decision: drop now) - Drop LSP (decision: not now) - Drop gas estimator (decision: maybe non-breaking) - Drop error recovering parser (decision: ask around) - Design decisions regarding operators: - Support for `!`, `<<`, `>>` and `**`. - Support for increment, decrement and assignments. - Should other comparison operators be automatically derived from `==` and `<`? - probably eventually, but that would be requested by the user explicitly - spaceship operator? - Do we want to ever allow external and/or non-pure operators? - external: never - operators on storage must necessarily be non-pure but we won't implement them now - Do we require definitions to be global and exclude library functions? - we think it's good like that but we could reconsider if people demand relaxing it - we want to have enough at least for PRBMath and this does not prevent that - Operators on structs and other reference types. - definitely not before we deal with locations but possible later - probably not directly on arrays but encapsulated in a user-defined type might be fine - tl;dr: not soon - Operators on mixed types. - not soon; we need to fit it into a generic type system - Should we disallow defining the same operator in multiple declarations? - yes, we can disallow it - Should we go back to building completely static binaries on Linux to avoid breakage due to glibc incompatibilities? - Daniel: we can't unless we want to drop SMT support or increase binary size by an order of magnitude. Also we don't have to, at least for now, we just need a compatible build CI run again. - Long-term we could think about interfacing with Z3 in a different way, without linking it into the binary. - [Support public functions in interfaces #13890](https://github.com/ethereum/solidity/issues/13890) - The proper solution is the inheritance overhaul planned for Q3. - Unclear if OZ will be fully satisfied with that. It will require replacing interfaces with abstract contracts. -