Support outside configuration values during compilation time

[axic]

With the upcoming JSON compiler interface it would be easy to supply a list of values with types, e.g. this would be a new section in the JSON input:

globals: {
  "name": {
    type: "string",
    value: "testToken"
  },
  "version": {
    type: "uint256",
    value: 42
  },
  "registryAddress": {
    type: "address",
    value: 0x42...
  }
}

These values could be either defined as contract level variables or more preferably a special method could be used to retrieve them:

contract A {
  function tokenName() returns (string) {
     return globals("name");
  }
}

Fixes #242.

[chriseth]

I would prefer this to be more explicit and part of the language at the same time. It could work as follows:

When compiling, you supply one file literally:

"globals": 'string constant testToken = "abc"; uint constant version = 42; address constant registryAddress = 0x42;'

And when you want to refer to them in Solidity code, you use:

import {testToken} from "globals";

[axic]

import {testToken} from "globals";

I like using imports for that. How about making this:

import {testToken};
import {testToken as globalTokenName};

Because I still do like defining them as a non-snippet.

[axic]

My current proposal is:

JSON I/O

globals: {
  "name": {
    type: "string",
    value: "testToken"
  },
  "version": {
    type: "uint256",
    value: 42
  },
  "registryAddress": {
    type: "address",
    value: 0x42...
  }
}

Contract:

import {name as thisTokenName};
import {registryAddress};

contract A {
  function tokenName() returns (string) {
    return thisTokenName;
  }
  function registry() returns (address) {
    return registryAddress;
  }
}

[cameel]

We discussed this on the call today:

• We'd prefer not to introduce any new syntax for this at the language level.
• Hardhat apparently already has a preprocessor plugin: hardhat-preprocessor so it does not need this feature.
• We already have support for file-level constants, which get you pretty close to this. You then only have to have a system for providing values for these constants rather than a full-blown preprocessor.
  • Conditions using such constants can be evaluated at compilation time, which means that if you use them in an if, the unused branch will be removed from your bytecode by the optimizer.
  • Even manually changing values of these constants is not that much more tedious than supplying parameters to the compiler. The real problem is the use case where values come from tool's own configuration and that will require specific support in every tool no matter whether compiler accepts the values as parameters or rendered into the source code.
• Overall this is something that would be better off done at the tool level because the amount of real work to do by the compiler here is very small and probably not worth complicating the interface. And it's actually redundant - instead of adding extra parameters to Standard JSON input, a framework can just do simple search and replace on sources included in it.
  • The problem here is that if every tool introduces its own syntax for it, switching between tools becomes harder. For example using a framework and vscode-solidity would be hard.
  • @axic proposed that we might be better off standardizing common templating syntax for these substitutions and letting each tool do the actual substitution on its own.

[cameel]

As for specific syntax proposal, we could standardize some kind of substitution marker. The {{ x }} from Jinja comes to mind, though double braces are a valid syntax so it should rather be something that would not clash. Maybe something like this:

enum BuildType {
    Release,
    Debug
}

uint constant MAX_SIZE = #{{ globals.max_size }};
string constant network = "#{{ globals.network }}";
BuildType constant buildType = BuildType.#{{ globals.build_type }};

Looking at the grammar, it seems that we're not using # for anything.

[mikebolt]

This would affect build reproducibility and require support from tools like etherscan.

[cameel]

This would affect build reproducibility and require support from tools like etherscan.

True, that's something to consider. Though on the other hand constructor arguments also have the same problem and Etherscan did solve it by requiring you to specify them. So this is not an unsolvable problem.

Looking at the grammar, it seems that we're not using # for anything.

Just wanted to note that if we go with this, we should not use # - it would interfere with the use of C preprocessor with Solidity (#10 (comment)).

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[github-actions]

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.