vyper init function doesn't recognize private function

[acheron2302]

Version Information

• vyper Version (output of vyper --version): 0.1.0b12+commit.ab39d4e
• Python Version (output of python --version): 3.7.4

What's your issue about?

The __init__ function doesn't recognize the private function even i have declared it before __init__ function. Here is a test code name test.vy

x: uint256

@private
def _set(_x: uint256):
    self.x = _x

@public
def get() -> uint256:
    return self.x

@public
def __init__():
    self._set(0)

When i compile it with: vyper -f abi test.vy. It split out this error:

Error compiling:  test.vy
vyper.exceptions.FunctionDeclarationException: Function not declared yet (reminder: functions cannot call functions later in code than themselves): _set

How can it be fixed?

I think the problem is that the parser parse __init__ function first and then it parse regular function. So i if we change the order of regular function is parse first then the __init__ function is parse second will work

[fubuloubu]

Thinking about this, I don't think it would ever be possible for this to compile, because the deployment transaction cannot call code prior to the contract being deployed. Is this thinking right? cc @jacqueswww @charles-cooper

Solution if this is true would be to raise an error if __init__() isn't the first function being defined (and maybe add a note to the error message that it is not possible to call other functions)

[charles-cooper]

I'm not sure that it's not possible. The runtime code is contained in the deployment code so theoretically it could jump to a location in the deployment code.

[fubuloubu]

This should raise during compilation. __init__ must be the first method, if specified.

[jacqueswww]

The only way to get this to work is to have the deployment inline the called functions. I think we could make this feature part of the @inline function work - as one could reuse the code . We would just have to add a disclaimer that it could potentially make

In general this is something I would say is good, because it's allows you to reuse code & more secure (for most instances I can think of anyways).

[fubuloubu]

But we don't have @inline now, when we do we can allow it