Meta-programming interface - ERC165 support

[axic]

While this topic can be fairly big and we have a couple of issues open already here I only suggest a fairly small, non-intrusive addition:

meta(<contract name>)

to return a meta object (similar to block, etc.). This would have the following defined currently:

• .signatures returns bytes4[] corresponding to the method signatures of the contract
• .name returns string as the name of the contract

The signatures could be utilised by proxy / filter contracts and for a way to implement interface checking between contracts (along the lines of ethereum/EIPs#165).

Two other possible methods:

• .pragma(<key>) returns string of the actual pragma value or empty string if not set (or should the return type depend on the pragma type?)
• .super returns meta[] corresponding to all the direct superclasses

[axic]

This could be augmented by compile-time execution of certain pieces of code. It should be possible to execute pure functions during compile time given there's a VM for the intermediate language of the compiler.

[VoR0220]

Following

[chriseth]

I would prefer type instead of meta and baseContracts instead of super (super has a special meaning). Since we do not yet assign pragmas to contracts and arrays are quite hard to do, I would postpone them.

[axic]

Using the above meta programming interface, ethereum/EIPs#165 can be implemented as a library:

contract ERC165 {
    function interfaceID() constant returns (uint)
    {
        bytes4[] sigs = type(this).signatures;
        uint mask = 0;
        for (var i = 0; i < sigs.length; i++)
            mask ^= uint(sigs[i]);
        return mask;
    }
}

contract Test is ERC165 {
  // ...
}

[chriseth]

@axic note that the type of this is always just the current contract (although all function calls are virtual). This means that interfaceID() will only contain the functions defined by ERC165 and not those additionally defined by Test.

[axic]

Right, we need templates then 😉

[axic]

In line with #1435 / #2473, .signatures should be renamed .selectors and a list of function types could be added, because then the selector can be retrieved on a function.

[axic]

I think it can be solved without templates too:

library ERC165 {
    function interfaceID(bytes4[] memory sigs) constant returns (uint)
    {
        uint mask = 0;
        for (var i = 0; i < sigs.length; i++)
            mask ^= uint(sigs[i]);
        return mask;
    }
}

contract Test {
  function interfaceID() constant returns (uint) {
    return ERC165.calculateInterfaceID(type(this).selectors);
  }
}

[chriseth]

Now that ERC165 is further towards standardisation - shall we add some kind of high level support for this?

[axic]

Right, we need templates then

An alternate solution to complete templates would be something like Ruby's mixins:

library ERC165 {
    mixin function interfaceID() constant returns (uint)
    {
        bytes4[] memory sigs = type(this).selectors;
        uint mask = 0;
        for (var i = 0; i < sigs.length; i++)
            mask ^= uint(sigs[i]);
        return mask;
    }
}

contract Test {
  mixin ERC165.interfaceID();
}

or

mixin ERC165 {
    function interfaceID() constant returns (uint)
    {
        bytes4[] memory sigs = type(this).selectors;
        uint mask = 0;
        for (var i = 0; i < sigs.length; i++)
            mask ^= uint(sigs[i]);
        return mask;
    }
}

contract Test {
  mixin ERC165;
}

Basically these are very restricted templates: no template parameters are supported, except that this always points to the type including it.

[chriseth]

Are there any more use-cases for that? Otherwise, I have the impression that it is too complicated and also too restricted at the same time.

[axic]

The best current solution I think still is this: #1447 (comment)

I am also wondering what are use cases there are now for mixins vs. templates. It Whether we want any of that complexity.

[ekpyron]

As a first impression I'm not a fan of the mixin syntax.
Apart from that:
Why should type(this) always be the type of the containing contract anyways? For that I could use type(C) (where C is the contract name) just as well... Maybe type(this) should only be allowed in internal functions and refer to the calling contract in libraries instead? EDIT: or maybe it shouldn't be allowed at all :-)?

[ekpyron]

The best current solution I think still is this: #1447 (comment)

I am also wondering what are use cases there are now for mixins vs. templates. It Whether we want any of that complexity.

Yes, for this particular case, I think that may be the simplest and best solution indeed.

[axic]

Now we have type(C).runtimeCode and type(C).initCode. And #6097 proposes type(C).name.

Updated proposal:

• .signatures returns string[] corresponding to the method signatures (name and parameter types of function) of the contract
• .selectors returns bytes4[] corresponding to the method selectors (truncated hash signature) of the contract

I'm not sure .signatures is needed, but .selectors can be used to implement ERC165.

[chriseth]

Might be a waste of memory, but sounds good!

[axic]

They are in their current form, however in the future with compile time evaluated expressions all these would only exists during compile time in most of the real use cases.

[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.