VIP [DRAFT]: Safely expose `DELEGATECALL` about vyper

[charles-cooper]

maybe the name proxies: makes sense instead of implements storage:

[charles-cooper]

Every single contract that uses storage slots needs to define it's storage layout:

all contracts implicitly define a storage layout just by declaring variables. so we could even skip the storage keyword and instead of having the storage layout be a named member on the module, just have:

proxies: parent

[charles-cooper]

@makemake-kbo what are you thinking as syntax for safely calling a contract via delegatecall?

a couple ideas:

delegatecall SomeContract(*args)

SomeContract.__delegate_call__(*args)

(both of these would presumably have a compile time check that SomeContract proxies self)

[makemake-kbo]

@charles-cooper
i think both look fine and would be ok with either. i have a slight preference for the first option

Every single contract that uses storage slots needs to define it's storage layout:

all contracts implicitly define a storage layout just by declaring variables. so we could even skip the storage keyword and instead of having the storage layout be a named member on the module, just have:

proxies: parent

the idea with the more verbose syntax was that using storage is something extra. i wanted to highlight the importance of storage, if that makes sense. another thing is that you could technically reuse the storage patterns but thats probably not that useful and might be harmful if missused.

id be fine with changing it if it adds confusion or if it looks too complicated.

[charles-cooper]

by the way, i want to point out that this proposal is useful even without the presence of delegatecall. for instance, off-chain tools might want to have the "storage layout interface" to figure out how to interpret the storage space of a contract.

[cyberthirst]

I like the idea.

I think that adding the storage kw is unnecessary. I would argue that the same holds even for the proxies kw - couldn't it be implicit in the use of delegatecall?

Also the word proxies seems to be a bit too narrow and not capturing the whole semantics of delegatecall.

How would the storage compatibility be defined? Slot addrs and type compatibility? I think that even syntactic compatibility is interesting (eg swapped two addresses in the logic - eg operator vs owner).

Lastly, I would rather opt for just a compiler warning rather than a compile error, seems too restrictive.

[charles-cooper]

How would the storage compatibility be defined? Slot addrs and type compatibility? I think that even syntactic compatibility is interesting (eg swapped two addresses in the logic - eg operator vs owner).

i think slot, type, and name should all be equal