Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add Constants library #654

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

CodeSandwich
Copy link

@CodeSandwich CodeSandwich commented Feb 4, 2025

Fixes #267. Gathers up all constants used throughout forge-std in a single library so they are easier to access.

The refactoring around the constants is minimal, it's mostly replacements of arbitrary values with references to the new library. No changes are visible from the outside, the 3 constants removed from StdUtil were private. Many more refactorings, like dropping other private constants that are used more than once or are variations about type(uintXXX).max, may be done in separate PRs.

@CodeSandwich
Copy link
Author

CodeSandwich commented Feb 4, 2025

Well, it doesn't compile with 0.6.2 as it doesn't allow assigning constants to constants, which defeats one of two purposes of this PR. A library with the constants is still useful for the forge-std users, but there's no way to deduplicate the constants inside forge-std without introducing breaking changes.

What should we do now?

  1. Only introduce the library, but don't use it internally.
  2. Drop support for Solidity 0.6.2 (It's a 5 years old compiler which has a smooth path of upgrade to the 4.5 years old 0.6.12. Does anybody use the 0.6 family for active development with modern tools in 2025?).
  3. Close this PR.

Edit: It's much worse, it breaks on anything below 0.8.16 which explicitly introduced assignment of library constants to other constants. I guess that the only way forward is to introduce the library and not use it internally until we drastically increase the minimum compiler version.

@zerosnacks
Copy link
Member

Hi @CodeSandwich, thanks for your PR

Why is inheriting the CommonBase contract where you want access to the constants an issue?

Given the described limitations I would prefer not duplicating these constants

Appreciate the clarifying fix on Base.sol, makes sense

@CodeSandwich
Copy link
Author

CodeSandwich commented Feb 5, 2025

Why is inheriting the CommonBase contract where you want access to the constants an issue?

It's discussed in #267. Inheritance is a barrier when accessing these constants, it excludes usage in libraries and free functions, which are excellent ways to create helpers and utilities for tests and scripts.

Free constants are another option, but they tend to pollute namespaces and they don't work with Solidity older than 0.7.4.

Expressing constants as free functions could work, but they would be clunky they wouldn't work with Solidity older than 0.7.1.

@zerosnacks zerosnacks requested a review from mds1 February 5, 2025 10:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Thoughts on creating a "StdConstants" contract?
2 participants