VIP: remove reduntand syntax for address to contract

[denis-bogdanas]

This is the suggested template for new VIPs.

Preamble

VIP: 748
Title: Remove reduntand syntax for address to contract
Author: Denis Bogdanas
Type: <Standard Track>
Status: Draft
Created: 2018-04-03

Simple Summary

There are at least 3 syntaxes for defining an address to a contract. Only one should be allowed for uniformity.

Motivation

Syntax redundancies should be eliminated to simplify the language and avoid confusion.

Specification

Right now there are at least 3 syntaxes to define an address to a contract:

1. For storage variables: https://github.com/ethereum/vyper/blob/5b70797a31ffcbdd90b1dfd98f7b38d306bca7a0/tests/parser/features/external_contracts/test_external_contract_calls.py#L390

2. For function parameters: https://github.com/ethereum/vyper/blob/5b70797a31ffcbdd90b1dfd98f7b38d306bca7a0/tests/parser/features/external_contracts/test_external_contract_calls.py#L393

3. For hardcoded ERC20 contract: https://github.com/ethereum/vyper/blob/5b70797a31ffcbdd90b1dfd98f7b38d306bca7a0/tests/parser/features/external_contracts/test_erc20_abi.py#L20

There's another aspect to consider. The syntax of casting to contract address: https://github.com/ethereum/vyper/blob/9eebb7c575545fcf880d815b9c888665dccbea51/tests/parser/features/external_contracts/test_external_contract_calls.py#L19

The option most coherent syntax of casting is 1: bar_contract: Bar. However option 3 looks best in isolation: bar_contract: address(Bar). So I suggest either keeping option 1, or adopting option 3, but changing the syntax of casting to something else. Is it possible to have address(Bar)(bar_contract).foo() ?

Backwards Compatibility

Versions no longer allowed will be replaced.

Copyright

Copyright and related rights waived via CC0

[fubuloubu]

I like version 1 best. I think it's still intuitive for the use case in version 2, i.e. the input arg is an address type that is assumed to be a contract that implements the Bar interface.

I think we should summarize this as interfaces instead of contracts. ERC20 is an interface standard.

[denis-bogdanas]

Related issue: modifiable/static attributes are currently not applied for syntax 2/3. Only for 1.

[fubuloubu]

I still wish modifiable/static was per method (replacing the pass keyword) instead of per contract interface. Each call is handled separately in a contract, and the bar: modifiable(MyContract) syntax is kind of busy...

[jacqueswww]

As discussed, we are going with option 1.

[fubuloubu]

I will create a separate VIP to address my last comment "denote static call per method in contract interface definition"

[jacqueswww]

Starting work on this, the syntax will be as follows:

Stored contracts defined as:

bar_contract: modifiable(Bar)
token: modifiable(ERC20)

Stored contract assigned as:

def foo(contract_address: address) -> int128: 
	self.bar_contract.address = contract_address

And on demand contract remain the same:

return Foo(arg1).foo()

[hustnn]

Can I know the relationship between ERC20 and address type? I am confused about it.

I have a storage:
token: ERC20

initilize with an address:
@public
def setup(token_addr: address):
assert (self.token == ZERO_ADDRESS) and token_addr != ZERO_ADDRESS
self.token = ERC20(token_addr)

contract Factory:
def getExchange(token_addr: address) -> address: constant

assert self.factory.getExchange(self.token) == self

We I can getExchange and got this error: vyper.exceptions.TypeMismatchException: Typecasting from base type address(ERC20) to address unavailable