Question: Contract address syntax and hardcoded contracts

[denis-bogdanas]

• vyper Version: latest as of 03/15/2018.

What's your issue about?

Question 1. I'm wondering why there's such a diversity of syntax for an address that refers to a contract.

Right now I see at least 3 different syntaxes:

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

Could they be replaced with one syntax in all contexts?

Question 2: Why ERC20 has to be hardcoded? Can it be explicitly defined in all contracts that need it? Are there any other hardcoded contracts?

[ben-kaufman]

Question 2: Why ERC20 has to be hardcoded? Can it be explicitly defined in all contracts that need it? Are there any other hardcoded contracts?

Personally I think it can be a good practice to add finalized ERCs to the as precompiled. I think it can be much more convenient and make the code more consistent.
I do agree all these different syntaxes are confusing and should change but IMO it is also good to keep the common finalized standards a part of Vyper itself.
I am pretty sure it's the only precompiled one currently. You can see it at https://github.com/ethereum/vyper/blob/master/vyper/premade_contracts.py
At least according to the name it is dedicated to all premade contracts but it currently only contains ERC20.

[fubuloubu]

I may have misspoke on it being a precompile in gitter, it's just a shortcut to that finalized ERC layout. I agree with above about how it's good to have these sorts of built in types available, but ERC20 does have some optional components and that makes this shortcut a little prescriptive. Something to think about moving forward.

I agree on the different syntax piece, it should be more standardized.

[denis-bogdanas]

I see, thanks for info. I'll implement then something similar to ERC20 interface in K-vyper.