VIP: add `method_id` member to interface functions

[iamdefinitelyahuman]

Simple Summary

Add a method_id member to interface functions:

from vyper.interfaces import ERC20

m: Bytes[4] = ERC20.transfer.method_id

Motivation

Currently, when using raw_call we have to generate the method ID from a string of the function selector, using the method_id builtin. Adding method_id as a member to interfaces is less error-prone and arguably more readable.

Specification

<INTERFACE>.<FUNCTION>.method_id

The member is accessible only from the primitive type:

# valid, accessing via the primitive
m: Bytes[4] = ERC20.transfer.method_id

# not valid, trying to access from a defined type
m: Bytes[4] = ERC20(_addr).transfer.method_id

Backwards Compatibility

Not a breaking change.

Copyright

Copyright and related rights waived via CC0

[Sporarum]

I know this was already approved, but I hope its not too late to change things:

In the following situation, method_id is under-specified:

def foo(x: uint256 = 0) -> uint256:
    return x

Since this method has two abi signatures: "foo()" and "foo(uint256)", and it's not clear which method_id encodes
(And of course this gets worse the more default parameters there are)

I'm also not sure what is the motivation for this, if we have access to the interface, what upside is there of going through raw_call ?
And if it is only to get the return raw, then something like raw extcall ERC20(_addr).transfer(...) seems like a cleaner solution

Nitpick: It would feel more pythonic for the name to be __method_id__, and it makes it more apparent something is going on.
(a.b.method_id can refer to method method_id of module a.b)

[Sporarum]

Re default args, current implementation uses the full signature (all args). Happy to change if a different behavior is preferred

Re naming (method_id vs method_id), FWIW, the reasoning in @Sporarum's #2098 (comment) makes sense to me

• @johnnyonline, feat: add method_id member to interface functions #4903 (comment)

[charles-cooper]

maybe it should be a builtin then, since method_id needs to know the number of kwargs

[johnnyonline]

Double checking i got this right -- extend the existing method_id builtin to accept a function reference, e.g. method_id(ERC20.transfer)

For functions with default args, maybe something like an optional n_args kwarg? e.g. for def foo(x: uint256 = 0) -> uint256, method_id(IFoo.foo, n_args=0) for foo() vs method_id(IFoo.foo, n_args=1) for foo(uint256)?

Want to confirm the desired API before reworking the PR

[charles-cooper]

Double checking i got this right -- extend the existing method_id builtin to accept a function reference, e.g. method_id(ERC20.transfer)

For functions with default args, maybe something like an optional n_args kwarg? e.g. for def foo(x: uint256 = 0) -> uint256, method_id(IFoo.foo, n_args=0) for foo() vs method_id(IFoo.foo, n_args=1) for foo(uint256)?

Want to confirm the desired API before reworking the PR

yea, i think it would be a new function, like method_id_of(...). n_args defaulting to 0 is good i think

[Sporarum]

n_args defaulting to 0 is good i think

I think not having a default is safer:

1. It forces the user to explicitly pick an override, better than debugging later
2. It allows us more flexibility, we might come to realize people would actually prefer the opposite default (maximum kwargs)

Or rather, there should be a default of None which does the above on functions with kwargs, and returns the unambiguous answer for the rest