VIP: disallow the use of `self` as an address

[charles-cooper]

Simple Summary

in vyper, self has type address. this VIP disallows that behavior and replaces it with self.address or context.address.

Motivation

can flesh out more but basically, it is not immediately clear what the type of self is (it deviates from the pattern set for other contract-like things, for interface addresses are accessed using the .address member).

Specification

change the type of self to the module type of the executing context. (not sure if this is practical because of ordering of steps in analysis, but it should look more or less like a module type). replace the current uses of self with self.address or maybe a new special variable context.address.

Backwards Compatibility

breaking change

Dependencies

If this VIP depends on any other VIPs being implemented, please mention them.

References

Add any references that this VIP might reference (other VIPs/issues, links to blog posts, etc.)

Copyright

Copyright and related rights waived via CC0

[fubuloubu]

I'm for this

Wonder if self should have a type Self (which is a special module type refering to itself)

[charles-cooper]

I'm for this

Wonder if self should have a type Self (which is a special module type refering to itself)

it would be more like Self is a special interface type refering to itself

actually i wonder if we should un-ban calling external functions. especially with https://github.com/vyperlang/vyper/issues/2856, there will be a syntactic distinction between self.internal_foo() and call self.external_foo()

[fubuloubu]

I'm for this Wonder if self should have a type Self (which is a special module type refering to itself)

it would be more like Self is a special interface type refering to itself

actually i wonder if we should un-ban calling external functions. especially with #2856, there will be a syntactic distinction between self.internal_foo() and call self.external_foo()

Don't have a problem with this, I think originally there is just a difference between internal and external calls (especially with dynamic types) and we wanted to avoid too much complexity in internal dispatching at least until the internals were refactored significantly

In solidity there is public interface decorator, I think we also wanted to avoid the waste of making a function public if it doesn't have to be (the compiler should handle this as well as function dispatch optimization)

[charles-cooper]

yeah i don't think we need the public thing -- it's pretty easy to factor code into internal implementation/external wrapper

[pcaversaccio]

I second this. Since the context is similar, I quickly link to my issue here: https://github.com/vyperlang/vyper/issues/3279. We should generally stop doing implicit address assignments IMO.

[michwill]

Doesn't matter a ton, but I like it when self is an address. And yes, I'd also like if contracts could be used as addresses!

[charles-cooper]

Doesn't matter a ton, but I like it when self is an address. And yes, I'd also like if contracts could be used as addresses!

hmm, well at least they should be consistent!

[charles-cooper]

And yes, I'd also like if contracts could be used as addresses!

it looks like prior to v0.2.0, this was actually the default behavior. the following (v0.1.17b!) vyper contract demonstrates:

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

factory: Factory
token: Factory

@public
def test():
   assert self.factory.getExchange(self.token) == self

this compiles in v0.1.17b. by v0.2.0, this contract (after updating the syntax) is rejected.

cf. https://github.com/vyperlang/vyper/issues/1375#issuecomment-478585521

[charles-cooper]

haven't made a decision yet here but leaning towards allowing (syntactically free) downcasting from interfaces to addresses. this is something we can do as a non-breaking change in the 0.4.x series.